[svk-devel] Help using svk in a staging development environment.

[Michael Brouwer]

If you want to fix a bug in a release branch, you should branch from that
branch and not from trunk.  If you branch from trunk and smerge your branch
to a release branch, that will end up merging all the changes on trunk since
the creation of your release branch to that branch as well.

Here is how we use svk.  Note that any of the branches can be local or
remote and that svk push and svk pull are really just shortcuts for svk
smerge with automatic selection of the second argument based on the copy
source of the branch you are on.

We develop the latest release on trunk, and have a release branch for each
older release.  If we need to fix a bug in an older release we branch from
that releases branch, fix the changes and smerge the change to that branch.
Then we smerge the release branch to trunk.  This ensures that anything
going into any older release is always merged to trunk as well.  In practice
we have multiple release branches and we do a "waterfall" smerge from the
oldest release forward to trunk.  svk sm //branches/r1.x //branches/r2.x;
svk sm //branches/r2.x //branches/r3.x; svk sm //branches/r3.x //trunk.

This scheme works unless changes are very different for different releases.
In that case you can make a new branch for the release that is different,
smerge the changes from the older release to that branch, rewrite them so
they work for the code in that release and smerge the change back to the
release branch, after which the waterfall merge can resume.

Michael


On 4/4/07, Brice Figureau <brice+svk at daysofwonder.com> wrote:
>
> On Wed, 2007-04-04 at 08:15 -0700, Michael Brouwer wrote:
> > Alway mirror the root of the repository with svk.  That way all
> > branches you make in svk can be either local (outside the mirror) or
> > shared (inside the mirror), plus you have access to all tags and
> > branches everywhere.  Other than that there is no right or wrong way
> > to use branches.  It's really your own choice.
>
> Hi Michael,
>
> Thanks. it makes sense.
>
> I thought a little bit more on this, but I still don't exactly see how I
> can "push" changes from a developpement local branch to let's say the
> release branch since my local developpement branch is not a children of
> the release branch but a children of the trunk.
>
> For instance, I have in my depot:
>
> //remote/www -> svn+ssh://<removed to protect the innocent>/www
>
> //local/devel is a copy of //remote/www/trunk
> //local/release is a copy of //remote/www/branches/release
>
> Then I have a local working copy for //local/devl where I'm coding and
> committing my changes. Other developpers do the same in their local
> working copies. When they think the changes are mature, they commit
> (push) those changes to  //remote/www/trunk.
>
> Now I have to release the website, so I have to merge the changes from
> the last known trunk to the release branch.
>
> I can't do: svk push //local/devel since it will push the changes to the
> trunk which has already been done.
>
> I suppose I have to do:
> svk smerge //local/devel //remote/www/branches/release
>
> is it the right thing to do ?
>
> What happens if there are conflicts ?
> How do I resolve them ?
>
> I'm sorry for those newbie questions, I'm still discovering SVK.
> It seems to be a really powerful tool, and the more I see about it, the
> more I like it :-)
> --
> Brice Figureau <brice+svk at daysofwonder.com>
>
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/svk-devel/attachments/20070404/fef12008/attachment.htm