Try merging your trunk changes to the branch first, "before"
merging your branch changes to the trunk. What happens then?
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Thursday, April 12, 2007 10:21 AM
>To: lsuvkne@onemodel.org; eli.carter@commprove.com;
>users@subversion.tigris.org; Hartleroad, James M [EQ]
>Subject: RE: Re: rename overwrites code: this a reasonable
>interim solution?
>
>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
>
---------------------------------------------------------------------
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:26:16 2007