You have a point. The SVN designers may be able to address
this...
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Thursday, April 12, 2007 10:33 AM
>To: Fouts Christopher (QNA RTP PT PREV); users@subversion.tigris.org
>Subject: RE: RE: RE: Re: rename overwrites code: this a
>reasonable interim solution?
>
>I can try it, but say my branch is a release branch and new
>next release is on the trunk. If so, in general merging from
>trunk to branch wouldn't be an option really - right?
>
>> -----Original Message-----
>> From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
>> Sent: Thursday, April 12, 2007 9:25 AM
>> To: users@subversion.tigris.org
>> Subject: RE: RE: Re: rename overwrites code: this a
>reasonable interim
>> solution?
>>
>>
>> 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
>>
>>
>>
>
---------------------------------------------------------------------
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:37:08 2007