[snip]
>
> 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?
Well, for us the big problem would be that the majority of our folks
will probably be using either Subclipse or TortiseSVN rather than the
command line.
For folks that use the command line exclusively, it sounds like it
should work, at least as far as I can see.
>
> (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?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 27 23:16:01 2007