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

RE: Merging Practices

From: Dale Worley <dworley_at_pingtel.com>
Date: 2005-01-31 18:21:18 CET

I don't know how Subversion handles this internally, but from your symptoms,
it seems that things must work more or less this way:

-----Original Message-----
From: Sean Laurent [mailto:sean@neuronfarm.com]

$ svn merge -r 807:810 http://server/svn/apps/main mytask

This works without a flaw, so I commit it.

So Template.fla has been changed on main. In principle, when Subversion
merges the changes from A to B into C, it is taking the diffs from A to B
and then applying them to C. But in this case, the Subversion database
records that A and C are identical, so it just copies C into your working
copy. Which is just as well, as Subversion doesn't know how to merge .fla

But it appears that Subversion does not record in its database that the
working copy is now identical to C.

A few days pass and development on
the main branch has been going gangbusters and I'm just about ready to merge
my branch changes back into main. To prepare, I merge main into mytask one
more time.

$ svn up main
At revision 833.

$ svn merge -r 811:833 http://server/svn/apps/main mytask

This time, things don't go as smoothly.

At this point, Subversion has to do a binary merge. You want to merge the
changes from B to D into your working copy, but it looks like Subversion has
no record that Template.fla in your working copy is already identical to B.
(Otherwise it would use the shortcut it used the first time.)

I suspect that this could be cured by updating your working copy as if (more
or less) "svn copy -r B http://.../Template.fla ./Template.fla" had been


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 31 18:26:43 2005

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