I'm new to Subversion and just learned about this problem. However it
seems to me that the problem described is just one instance of the
underlying problem, i.e. the way that Subversion implements renames.
Here's probably a more serious instance of the problem.
Say you have a project with directory structure:
aDir
file1.txt
Say you make a branch, aBranch, of this project, so you've got:
Repo
project
trunk
aDir
file1.txt
And
Repo
project
branches
aBranch
aDir
file1.txt
Now say that I use svn renaming to rename aDir in the branch to be
aDirNew and commit my changes.
Also, in the trunk I modify the contents of file1.txt and add a new
file, file2.txt, under aDir, and then commit my changes.
Now if I merge aBranch down to the trunk there will be no conflicts
reported, which is what I would expect. If I then commit my changes, I
lose most recent changes that I made to trunk in the resulting revision,
i.e. the change to file1.txt and the addition of file2.txt.
I've verified that this does seem to be what happens.
It would be great to hear if someone has a way to guard against such
code loss - anyone? Thanks
Chuck
> -----Original Message-----
> From: lsuvkne@onemodel.org [mailto:lsuvkne@onemodel.org]
> Sent: Wednesday, April 11, 2007 10:14 PM
> To: eli.carter@commprove.com; users@subversion.tigris.org
> Subject: Re: rename overwrites code: this a reasonable
> interim solution?
>
>
> >>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 12 16:22:00 2007