[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 6715 - in branches/neon-0.24

From: <kfogel_at_collab.net>
Date: 2003-08-12 20:43:34 CEST

"Sergey A. Lipnevich" <sergey@optimaltec.com> writes:
> Apparently, sorry about that... I don't remember anything about this
> in the HACKING ;-).

It wouldn't be in there, it's a general branching technique not
specific to Subversion.

> > You just merged a bunch of changes into trunk. The procedure for
> > rebranching is:
>
> You mean, /from/ the trunk?

No, I mean *to* the trunk, in revision 6713.

Then, later, in 6715, you merged from trunk to branch, which is what
this thread is about.

> > 1. Delete the current Neon-0.24 branch, since all (or 90%) of those
> > changes are in trunk now.
> > 2. Create a new Neon-0.24 branch, based on the post-merge trunk.
> > 3. Port any remaining changes from your old Neon-0.24 branch to the
> > new one ("remaining" means ones that were not merged into trunk).
> > There's no point merging changes from branch into trunk, and then
> > immediately back into the branch again :-)... That doesn't get you
> > anything.
>
> I think it does, it does steps 2 and 3 for me. I have actually did the
> same thing in one step, `merge r X:Y trunk-url' (being in the branch
> WC), the way I'm used to in CVS :-) (maybe that was my principal
> mistake). Now, I'm not sure if this brings forth any database space
> issues, but with a single revision 6715 I have the same result as you
> would have, and I saved two revision numbers ;-).

There is no scarcity of revision numbers, the integers are infinite :-).

The more important thing is clarity. It's hard to tell why these
various copies are happening. By merging many changes from trunk to
branch, you create the misleading appearance of huge code churn --
whereas if you had just copied a new branch, there would have been one
"point of copy" in the history and it would have been very clear
what's going on (the number of paths changed in 'svn log -v' output
would be much lower, for example).

Look at it this way: why did you intially merge your changes into
trunk if you were not going to then recopy from trunk? You might as
well have done *only* revision 6715, and not bothered with 6713, and
just continued branch development.

Does this explain it better?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 12 21:24:33 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.