>>> Eli Carter <eli.carter@commprove.com> 04/11/07 1:25 pm >>>
>What about wrapping svn merge in a script to check for the problematic
>case and fixing up the problem?
>Eli
Thanks for the suggestion. Do you mean something doing like this?:
1) merge wrapper first does a "merge --dry-run ...", and checks for an
add/delete pair, and somehow (?) determines that a file has been renamed
(I'm not sure how this would reliably be done--maybe the log of the
added copy of the renamed file would tell where it came from? or some
other way) and gets the pre-rename path and name for the file(s).
2) then does a check to see if the other instance of that file, w
hich is in the subversion repository where the merge is to be committed,
has a last changed revision # which is greater than the last changed
revision # of the file that was deleted/added in the "source" repository
for the diff/merge info. If so, stop with an error. If not, proceed
with the merge.
3) Probably aft
er the commit, the script would check the revision #'s again to be sure
the last changed revision # for the file deleted in the target of the
merge was still not greater, and alert the user if there was a problem.
This sounds like it might have more opportunity for error, at least in
that it requires the user to remember two special commands instead of
one. Hmmm.
Also I think there is another problem with doing that, caused by the
fact that we would need to propagate this changeset not only in the
first scenario (say, "multiple task branches to stabilization branch")
but then farther up the line to other branches as well ("stabilization
branch to release line"). Say we have the following:
- a "release line"
- various "task branches" where work occurs (derived from the release
line)
- a "stabilization branch" (also derived from the release line)
..and the first pass through the edit+rename+merge cycle occurs on two
task branches. File is edited on one (creating revision 20), renamed on
the other (revision 21), and edited again directly on the release line
(revision 22), then the changes from the task branches are merged to a
stabilization branch (the edit and rename, merged in that order then
commit revision 23 to stabilization). By using the above steps 1-3 on
the merge of the rename from the 2nd task branch to stabilization, we do
not catch the rename problem because step #2 is checking the revision #
on the release line (still revision 20) and we overwrite the edit,
during the merges to the stabilization branch, and commit revision 23.
But even if we were somehow able to handle revision 23 in a way that
made it correct, we still need to merge the changes from the
stabilization branch back to the release line. The release line has a
file edit, created during revision 22. The edit from stabilization is
applied to the file, then the rename, and above steps 1-3 don't help
because they don't realize that the rename in revision 23 should not
overwrite the edit of revision 22, and that edit is lost.
So did I completely misunderstand your suggestion (quite possible), or
could you help me by clarifying? Otherwise, I'm back to the idea of
locking all lines that have this file in them, with a message saying
there was a rename to watch out for.
(The idea of locking all same-named files doesn't address the issue of
branches created after the lock by copying from a tree that doesn't
have the file rename in it--we still might have to do something ugly
like look for pre-existing locks and applying similar ones, if the
existing lock comments specify a revision # greater than that of the
pre-rename file being copied.)
Did I misunderstand your suggestion? Is there something else we might
try, or could the locking scheme possibly work out?
Thanks again!
-Luke-Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 12 05:14:13 2007