[svk-devel] ask help about svk smerge

[Jared Hardy]

On 3/6/07, Kevin Li <Kevin.Li at active.com> wrote:
> We have a subversion reposity in North America and want to create a mirror
> in Xi'an using svk. So let's assume that mirror is //mirror and then do:
>
> Svk cp //mirror //local
>
> then we got a copy of the mirror //local, and we use this copy as a server
> in Xi'an. So developers in Xi'an will checkout from here and commit to
> //local.
> Then maybe in the evening when developer go back, we will do smerge of
> //mirror and //local.

>From this description, it sounds more like you want to use CLK's
"pushmi" tool, or a Subversion 1.5.x server with reverse-proxy
capability, in combination with using a constant svnsync from the
source North American repository, via a post-commit hook script.
Either way, I think you want to be able to use the server in Xi'an as
if it were the main Subversion server (for fast updates), but actually
have all commits go back to the main server in North America,
transparently. In both cases, most of your developer's time will be
spent getting updates, which is a good reason to have a local server,
even just a "proxy" server. Individual atomic commits tend to be a lot
smaller, and happen less frequently,  than updates. Waiting for
commits to get back to the North American server may be easier in the
end, than dealing with batched conflicts nightly. Dealing with
conflicts immediately, with each atomic commit, will generally be
easier than dealing with a larger pile later, and reduces the risk of
mixing unrelated commits into dirty atomic sets.

    Another way to improve your cross-continental work-flow is to set
up a branch for each developer, and set up scripts that merge from
each developer's branch to your local server's trunk on a regular
basis. Alert the developer of conflicts as quickly as possible.
Perhaps you could precede every commit command with an update, and
make a pre-commit hook script on the server that fails to commit if
there are conflicts with local trunk, or a post-commit hook that sends
an IM or e-mail right away. Then your nightly script, that merges
changes back to North America, could smerge from one developer branch
at a time, and fail the smerge if there are conflicts, to prevent
polluting the North American trunk. That way, conflicts made by one
developer wont prevent other developers' changes from continuing to
merge, and wont halt all production while they deal with the
conflicts.
    Your scripts, which control the flow of merges from branch to
branch, could grow more sophisticated over time. You could even do
"test merges", and run unit tests on the results, to automate
prediction/prevention of merge and change issues. After all, branches
are cheap, good/simple scripts are written once, and developer time is
expensive.

:) Jred