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.



Regardless of the outcome, suppose, for round 2, that instead of "paint.colour" being a text file, it was binary. Suppose also that it was modified in "trunk" since branching. Here's the simple version of the user's operations (and console transcript again attached, as round2.txt), on an empty "bikeshed" folder in the "test" repository:

1 - Performs a checkout of "bikeshed" (revision 375).
2 - Adds a "trunk" folder.
3 - Adds a "paint.colour" file.
4 - Sets the mime type to binary.
5 - Commits at revision 376.
6 - Branches "trunk" to "branch" at revision 376 and adds the "brush.type" file.
7 - Commits at revision 377.
8 - Adds the "roof.composition" file in "trunk".
9 - Commits at revision 378.
10 - Modifies the "paint.colour" file from the "trunk".
11 - Commits at revision 379.
12 - Performs a "pull merge" to get the changes from "trunk" into their "branch".
13 - Commits at revision 380.
14 - Performs a "push merge" to have their "branch" be incorporated into "trunk".

The following is displayed:
C bikeshed\trunk\paint.colour

Is there really a conflict of paint.colour in this case? The "branch" obtained the new version through the "pull" merge in step 12 and the files in both branches are thus identical! Is this Subversion simply being extra careful or did I get my revision ranges wrong when merging? If the former, is it necessary to call it a conflict if the files are _identical_ in both folders?



And for round 3, I give you the scenario of the twice-conflicted file. Still the "test" repository, this time in the "deli" empty folder, here's the user scenario (with transcript in attached round3.txt):

1 - Performs a checkout of "deli" (revision 385).
2 - Adds a "trunk" folder.
3 - Adds a "sandwich.txt" file as the pre-conflict version in http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.cycle.resolve.byhand
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Creole Mustard
Bottom piece of bread
4 - Commits at revision 386.
5 - Branches "trunk" to "branch" at revision 386.
6 - Commits at revision 387.
7 - Modifies the "trunk" version by adding the lines Sally added after "Provolone":
Sauerkraut
Grilled Chicken
8 - Commits at revision 388.
9 - Modifies the "branch" version by adding the lines the other guy added after "Provolone":
Salami
Mortadella
Prosciutto
10 - Commits at revision 389.
11 - Performs a "pull merge" to get the changes from "trunk" into their "branch".
12 - Fixes the conflict NOT in the same manner as the documentation; that is we still remove the "Sauerkraut" inserted in step 7 but we'll keep the "Grilled Chicken" between the "Salami" and the "Mortadella".
13 - Marks the file/sandwich as resolved.
14 - Commits at revision 390.
15 - Performs a "push merge" to have their "branch" be incorporated into "trunk".

The following is displayed:
C deli\trunk\sandwich.txt

...but I just *fixed* the conflict in "branch"! Did I again get my revision ranges wrong when merging?? This one is a bit more of a problem for us, since we're trying to use branches in place of patches and so the "committer" applies "push merges" instead of applying patches. When a patch doesn't apply cleanly because of a conflict, a committer would normally get the submitter to perform an update first, fix anything if necessary and then resubmit. The thing is, there doesn't seem to be an equivalent operation the submitter can do here, save for performing the "push merge" at their end, resolving the conflicts (a second time) and submitting a patch or a copy of the resolved file alongside the "push merge" request.


Anyway, those are the scenarios we ran into today, except that all three showed up in a single "push request"! We're new at this intensive branch-and-merge thing, so we're sort of hoping we're simply doing something wrong. If not, then hopefully these scenarios will help the Subversion developers improve this wonderful software.

And, of course, here's the obligatory version dump:
18:19:29 test>svn --version
svn, version 1.4.3 (r23084)
   compiled Jan 18 2007, 07:47:40

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme


...now if you'll excuse me, all this talk about sandwiches has made me hungry.

Thanks in advance!


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Olivier Dagenais
Software Engineering / Génie logiciel
Formark - Combine the Best of SharePoint® and Livelink®
Phone: 613-599-5173 ext 238
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Make sure you don't miss anything: subscribe to the Formark Newsletter:
http://www.formark.com/support/register/index.asp

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org