I didn't read your detailed logs to confirm this, but I wonder if the problems
are because of the bidirectional merging, combined with svn's current
lack of merge tracking. In other words, when you 'push merge' from
branch to trunk, you're giving it a revision range, from which it
simply calculates a set of changes to apply by doing a diff--and
that set of changes includes changes that were just pushed into
branch FROM trunk. So it doesn't know it's sending the same change
right back.
Hopefully merge tracking (a work in progress by the developers;
sounds like it is to come out in version 1.5) will address this.
In the
meantime, you might want to google for "svnmerge.py" and check
out the wiki page on it at orcaware.com, including its "bidirectional"
feature; it's a very nice tool. I haven't enough experience with SVK
to say whether it would help you, but some people do use it. I'm
also working on changes to svnmerge.py that might help as a
workaround to the "rename = copy+del, resulting in potential
data loss" problem
(http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.moves).
> -----Original Message-----
> From: Olivier Dagenais [mailto:olivier.dagenais@formark.com]
> Sent: May 4, 2007 08:57
> To: users@subversion.tigris.org
> Subject: Some observations while branching and merging...
>
> As suggested on the issue tracker page, I'm posting here first to
> discuss my observations and see if they are worth logging as bugs
> and/or enhancement requests. My apologies if this reaches the mailing
> list twice: I sent the first one without being subscribed to the list
> and when I didn't see it in the archives ~12 hours later, I figured I
> needed to subscribe before posting. (the website isn't clear on this)
>
>
> So here's the first scenario. Suppose we have a "test" repository
> with a "bikeshed" folder in it that's totally empty. The user then
> performs the following operations (you can follow along with a console
> transcript, attached as round1.txt):
>
> 1 - Performs a checkout of "bikeshed" (revision 355).
> 2 - Adds a "trunk" folder.
> 3 - Adds a "paint.colour" file.
> 4 - Commits at revision 356.
> 5 - Branches "trunk" to "branch" at revision 356 and adds the
> "brush.type" file.
> 6 - Commits at revision 357.
> 7 - Adds the "roof.composition" file in "trunk".
> 8 - Commits at revision 358.
> 9 - Deletes the "paint.colour" file from the "trunk".
> 10 - Commits at revision 359.
> 11 - Performs a "pull merge" to get the changes from "trunk" into
> their "branch".
> 12 - Commits at revision 360.
> 13 - Performs a "push merge" to have their "branch" be incorporated
> into "trunk".
>
> The following is displayed:
> Skipped missing target: 'bikeshed\trunk\paint.colour'
>
> That file was deleted in the "trunk" and through the "pull" merge in
> step 11 was also deleted in the "branch". Both folders no longer have
> any (visible) record of that file. Should a warning really be issued?
> I would think it shouldn't be, but then again I may have misunderstood
> how I'm supposed to specify the revision ranges when pulling and
> pushing.
>
>
> <snip...>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 22 16:55:33 2007