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 04:16:43 2007