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&searchText=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:30:36 2007