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:33:26 2007