You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by tr...@clayst.com on 2005/11/05 12:58:38 UTC
Merge One Direction or Both?
Folks ...
I have a situation that seems fairly typical:
branch 'live' could be called the trunk, it's the live code and I
make small bug fixes and revisions here, committed each time I
am ready to update the site (it's a web project)
branch 'dev' is where I do major development work on new features
When I complete some work in dev I have a couple of options:
(1) Merge changes from live into dev first so that dev picks up the bug
fixes. Then merge from dev back to live to update the trunk with the
new features. Will this work? How would I choose which revisions to
merge for the second merge?
(2) Use svn diff to find the changes in the live branch that are not
yet in dev and make them manually, then merge changes only one way,
from dev to live.
(3) Merge from dev to live then delete the dev WC and get a new one off
the live branch as the base for future development.
Any tips here?
#3 seems like the cleanest approach but it is complicated by the fact
that I have bunch of unversioned stuff in the dev deirectories that I
wouldn't want to lose, so I can't just delete the WC and do another
checkout. Is there any way to remove all the versioned files from a
directory tree, leaving only what is unversioned?
Thanks,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by tr...@clayst.com.
On 8 Nov 2005 Gavin Lambert wrote:
> Well, it's better to first commit your changes from the dev WC to the
> dev branch (making r31 in dev). *After* that you merge r28:31 from live
> into dev and resolve conflicts, then commit again, making r32. Then if
> you're happy terminating the branch, you can switch to live, merge
> r28:32 from dev to live, and commit r33.
>
> That way it's more obvious what changes the merge is making, and you can
> back it out if something went fubar.
Fair enough. Thanks for the tip.
> > But what about this:
> >
> > At r27 the two branches are synchronized (last merge)
> > 'Live' branch has some changes committed in r28 and r30
> > 'Dev' branch has some changes committed in r29 and r31
> > 'Dev' branch has also been updated (WC only)
> > Merge live changes from r28:30 to dev, should work as above
> > Commit dev as r32
> >
> > Now, how do I get the dev changes back into the live branch? What
> > revisions do I merge? The interlacing makes it very confusing.
>
> 1. Commit dev (r32)
> 2. Merge r28:32 from live into your dev WC (HEAD is 32)
> 3. Resolve any conflicts, make sure everything still works ok
> 4. Commit dev (r33)
> 5. Switch to your live branch
> 6. Merge r28:33 from dev into your live WC (HEAD is 33)
> 7. Make sure things are still ok
> 8. Commit live (r34)
>
> (In step 2, since r29 and r31 only contained changes to the dev branch,
> there won't be any modifications in the live branch for those revisions.
> So merging them is a no-op and quite safe.)
This makes sense but what concerns me is your step 6. r28:33 on the
dev branch contains all of the r28:32 changes from the live branch so
they are being applied back to live. This seems like a recipe for
problems but I am not sure I can mentally construct a good enough set
of test cases to see if that hunch is right or wrong.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth trlists@clayst.com <ma...@clayst.com>:
> However ... imagine this scenario:
>
> At r27 the two branches are synchronized (last merge)
> 'Live' branch has some changes committed in r28 - r30
> 'Dev' branch has also been updated (WC only)
> Merge live changes from r28:30 to dev -- this gets bug fixes
> into the dev branch -- and resolve any conflicts
> Commit dev as r31
>
> Here I think it's simple -- if dev has not been committed since r27 I
> can just merge dev changes from r27:31 back to live. Right?
Well, it's better to first commit your changes from the dev WC to the
dev branch (making r31 in dev). *After* that you merge r28:31 from live
into dev and resolve conflicts, then commit again, making r32. Then if
you're happy terminating the branch, you can switch to live, merge
r28:32 from dev to live, and commit r33.
That way it's more obvious what changes the merge is making, and you can
back it out if something went fubar.
> But what about this:
>
> At r27 the two branches are synchronized (last merge)
> 'Live' branch has some changes committed in r28 and r30
> 'Dev' branch has some changes committed in r29 and r31
> 'Dev' branch has also been updated (WC only)
> Merge live changes from r28:30 to dev, should work as above
> Commit dev as r32
>
> Now, how do I get the dev changes back into the live branch? What
> revisions do I merge? The interlacing makes it very confusing.
1. Commit dev (r32)
2. Merge r28:32 from live into your dev WC (HEAD is 32)
3. Resolve any conflicts, make sure everything still works ok
4. Commit dev (r33)
5. Switch to your live branch
6. Merge r28:33 from dev into your live WC (HEAD is 33)
7. Make sure things are still ok
8. Commit live (r34)
(In step 2, since r29 and r31 only contained changes to the dev branch,
there won't be any modifications in the live branch for those revisions.
So merging them is a no-op and quite safe.)
I'm fairly sure that this is the correct procedure, anyway :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by tr...@clayst.com.
On 7 Nov 2005 Gavin Lambert wrote:
> Quoth trlists@clayst.com <ma...@clayst.com>:
> > (1) Merge changes from live into dev first so that dev picks
> > up the bugfixes. Then merge from dev back to live to update the
> > trunk with the new features. Will this work? How would I choose
> > which revisions to merge for the second merge?
>
> This is the typical approach, AFAIK. The process is explained in the
> SVN book, but AFAIK you basically just need to remember which revision
> was HEAD in 'live' when you branched (or last merged from it). Then you
> can merge in any changes made since then. Typically you do this by
> noting it in the comments for the branch.
Thanks for the response.
That part I've done before. It's a bit confusing because the book
mentions "stop on copy" but that methhod doesn't work if you are
continuously maintaining two branches and resynchronizing them from
time to time. There is no copy in that scenario except the original
one. But I do have the comments when I merged that show what revisions
were merged.
However ... imagine this scenario:
At r27 the two branches are synchronized (last merge)
'Live' branch has some changes committed in r28 - r30
'Dev' branch has also been updated (WC only)
Merge live changes from r28:30 to dev -- this gets bug fixes
into the dev branch -- and resolve any conflicts
Commit dev as r31
Here I think it's simple -- if dev has not been committed since r27 I
can just merge dev changes from r27:31 back to live. Right?
But what about this:
At r27 the two branches are synchronized (last merge)
'Live' branch has some changes committed in r28 and r30
'Dev' branch has some changes committed in r29 and r31
'Dev' branch has also been updated (WC only)
Merge live changes from r28:30 to dev, should work as above
Commit dev as r32
Now, how do I get the dev changes back into the live branch? What
revisions do I merge? The interlacing makes it very confusing.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Merge One Direction or Both?
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth trlists@clayst.com <ma...@clayst.com>:
> (1) Merge changes from live into dev first so that dev picks
> up the bugfixes. Then merge from dev back to live to update the
> trunk with the new features. Will this work? How would I choose
> which revisions to merge for the second merge?
This is the typical approach, AFAIK. The process is explained in the
SVN book, but AFAIK you basically just need to remember which revision
was HEAD in 'live' when you branched (or last merged from it). Then you
can merge in any changes made since then. Typically you do this by
noting it in the comments for the branch.
> (2) Use svn diff to find the changes in the live branch that are not
> yet in dev and make them manually, then merge changes only one way,
> from dev to live.
That's pretty much the same as #1, except that you're doing the grunt
work yourself :)
> (3) Merge from dev to live then delete the dev WC and get a
> new one off the live branch as the base for future development.
This won't work if people other than yourself are committing things to
'live'. Or if you're committing things to 'live' from outside the dev
branch. Which sounds like the case if you're worried about stray bugfix
code in the first place.
> #3 seems like the cleanest approach but it is complicated by the fact
> that I have bunch of unversioned stuff in the dev deirectories that I
> wouldn't want to lose, so I can't just delete the WC and do another
> checkout. Is there any way to remove all the versioned files from a
> directory tree, leaving only what is unversioned?
svn switch would probably work. Either switching to the latest branch
or to an empty folder. But I don't think #3 is the way to go anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org