A very low-tech approach would be to try to wait to do renames until
there is only one active development stream. (Yuk! I know...). Or maybe
wait until there are only two active releases, RN and RN+1, where RN is
in production and there are mainly only bug fixes happening on it. Do
your renames on RN+1 and manually apply bug fixes found in production to
both releases.
And.... beg, plead, hope, cajole that renaming will be fixed so that it
can reliably be used in the context of merging. ;-)
Chuck
> -----Original Message-----
> From: Justin Johnson [mailto:justinjohnson@gmail.com]
> Sent: Friday, April 27, 2007 10:30 AM
> To: lsuvkne@onemodel.org
> Cc: Irvine, Chuck R [EQ]; users@subversion.tigris.org;
> eli.carter@commprove.com; Chris.Fouts@qimonda.com
> Subject: Re: yet better rename approach?: (was RE: rename
> overwrites code: this a reasonable interim solution?)
>
>
> Wrapping up client commands isn't really an option for me.
> There are too many clients to make this feasible (command
> line, TortoiseSVN, IDE plugins).
>
> I was thinking it would make more sense to make svnmerge.py
> smarter and handle renames more gracefully. The update issue
> would still require user training, but for me that is a much
> smaller issue than merging.
>
> I wrote a script that parses revisions from the log and
> determines if a rename happened. It seems like svnmerge.py
> should be able to detect when something was renamed and make
> sure changes aren't lost. It may require asking the user
> which file/directory should be kept (i.e. what history to
> preserve) and then it can merge the lost changes into that
> file/directory.
>
> Does anyone know of a reason why this wouldn't work? Has
> anyone thought of doing this before?
>
> Justin
>
> On 4/26/07, lsuvkne@onemodel.org <lsuvkne@onemodel.org> wrote:
> > On 04/20/07 Chuck.R.Irvine@Embarq.com wrote:
> > >I think I asked you this already, but do you think your approach
> > >below deals with the following situation. Say I have branch:
> > > <snip. rest of thread at
> >
> >http://subversion.tigris.org/servlets/SearchList?list=users&searchTex
> > >t=rename+overwrites+code&defaultField=subject&Search=Search
> > >
> >
> > I apologize for my long delay in replying. You ask a good
> question; it
> > would depend on the implementation I guess. We talked further about
> > it, where I work, and decided the various troubles, like
> dealing with
> > all those locked files when doing merges across the various
> branches,
> > were going to require too much manual intervention, even if we sent
> > email instead of locking. So we came up with a different, hopefully
> > better approach, that might also address your question
> about renaming
> > directories or packages.
> >
> > We'd like to write a temporary wrapper around 'svn rename' and 'svn
> > merge' which would essentially do the following:
> > 1) the rename command would, in addition to what rename
> normally does,
> > put a string in the properties (or somewhere) on both the
> old and new
> > file, indicating that they were involved in a rename operation, the
> > to/from relative paths & filenames, the branch URL (shared
> portion of
> > to/from), the developer's name (or username), and the
> date/time. (We
> > might also save this information off to an external log
> file somewhere
> > for reference in case a human wants to know later for some reason.)
> > 2) the merge command would
> > 2a) do a --dry-run and scan the list of adds and
> deletes provided,
> > query svn for the properties associated with those files being
> > added/deleted, and find matching pairs that constitute
> renames. If a
> > directory was renamed, it would have to figure out all the
> > path/filenames pairs involved.
> > 2b) calls svn merge the normal way
> > 2c) Using the information from step 2a, it does a merge of any
> > changes in the old path/filename being deleted into the new
> > path/filename being added, in the local working copy.
> Then we should
> > be safe.
> >
> > That helps w/ many cases but leaves loose ends: We'll
> still have to
> > train people carefully on what to do when they get error
> messages from
> > an update command (file missing, or status showing
> unversioned files),
> > to avoid that potential problem scenario (described earlier in the
> > thread). Theoretically we could also wrap the update command, but
> > later. Similarly for times when they are trying to merge
> edits into a
> > branch with renamed files--so they are alert to handle properly the
> > fact that the merge reports a "missing file" or such (this
> is a place
> > where that external log file with rename information could
> be helpful
> > to them). We'd also have to consider whether in our wrapper
> we want to
> > prevent merges that operate directly on the server (if such are
> > possible)--and make sure it always happens in a working copy, and
> > whether to prevent scenarios that are outside what we can
> handle. I
> > still have to think about integration with svnmerge.py,
> prove the idea
> > and work out kinks with some experiments, then a prototype
> and further
> > testing...
> >
> > ..but do you see problems with the idea so far?
> >
> > (I've briefly considered using current rename branch of svn
> with its
> > svn-move.py script, but after reading some postings and the rename
> > todo list kept in that branch, I was quite unsure whether
> it would be
> > safe to use at this point, even in very carefully limited
> situations.
> > If it were, that *might* of interest.)
> >
> > Of course, this would be only until "real" rename is implemented in
> > svn. Maybe someday after we get this quicker fix going we can help
> > with that.
> >
> > Thoughts?
> >
> > -Luke
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 27 17:47:19 2007