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

Re: svn commit: r23221 - in branches/fs-atomic-renames: . build build/ac-macros build/generator build/generator/swig build/win32 contrib/client-side contrib/client-side/psvn contrib/client-side/svn2cl contrib/hook-scripts contrib/server-side contrib/

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-01-28 22:37:45 CET

On 1/28/07, Paul T. Burba <ptbsvn@adelphia.net> wrote:
>
> Erik Huelsmann wrote:
> > On 1/24/07, pburba@tigris.org <pburba@tigris.org> wrote:
> >> Author: pburba
> >> Date: Wed Jan 24 13:16:05 2007
> >> New Revision: 23221
> >>
> >> Log:
> >> Merge r21513-23186 via svnmerge.py from trunk into the
> >> fs-atomic-renames branch.
> >>
> >
> > Wasn't rebranching easier?
>
> Hi Erik,
>
> svn/branches/fs-atomic-renames was recreated by rooneg in r18692, but he
> merged up to trunk many times after that, the last time being r21513 back
> on
> 9/15/06. Since I was taking a look at the branch I thought there was no
> harm
> in catching it up with trunk.
>
> Or am I misunderstanding what you are asking? I'm not totally sure I
> follow
> your question :-\ Anyway, let me know if this doesn't answer your
> question.

I think he was suggesting that it would have been easier to just delete the
branch, create a new one from the current trunk, and then apply the diff of
the old branch and the revision of trunk it was last merged with.

You somewhat lose the history when you do this. If you look at the current
branch, Garrett did something similar a while back.

Since you have already merged, it doesn't matter. It just likely would have
been a smaller commit to do it the other way. Personally, as long as the
merge applied relatively cleanly, I think you probably did the right thing.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Sun Jan 28 22:38:08 2007

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.