[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: yet better rename approach?: (was RE: rename overwrites code: this a reasonable interim solution?)

From: <lsuvkne_at_onemodel.org>
Date: 2007-05-12 18:08:23 CEST

>> > 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.
>> What is the reliable logic to determine if a rename happened? Like
>> if a directory (java package) is renamed, or if there are other adds
>> & deletes at the same time? I didn't see a way but if it works, then
>> modifying svnmerge.py sounds attractive.
> Here is sample log output for clarification.
> C:\work\testwc2>svn log -v -r 14
> ------------------------------------------------------------------------
> r14 | jjohn53 | 2007-04-26 13:46:33 -0500 (Thu, 26 Apr 2007) | 1 line
> Changed paths:
> A /trunk/foo.txt (from /trunk/new_file.txt:12)
> D /trunk/new_file.txt

(Sorry again for the delayed reply; it seems to be going that way

I like what you're saying. I'm thinking of trying to make modifications
to svnmerge.py so that it does use logic like your perl script, to parse
the log output and to determine if a rename happened, and if so, then
before actually doing the Add+Delete caused by a rename, it would do an
'svn diff...' to create diff files for any uncommitted changes to the
files about to be deleted, then do the full merge (add+del), then apply
the created diff files to the newly added ("renamed") files.

One drawback (manageable for us) is that it will require the user to
have a patch utility locally installed; this could be a major drawback
if it is seen as causing headaches for general/simple svnmerge.py
installation on computers that don't come with a patch utility, so I
don't know if the svnmerge.py maintainers will be pleased to incorporate
such a modification. Maybe there's a workaround for that, or some better
approach. If there were a way to apply a diff file from svn, that would
be nice but I don't see it.

Also, I am not sure that we would have to ask "the user which
file/directory should be kept", as you suggest--could we just assume
instead that the add/delete will be carried out as specified (preserving
uncommitted changes to the deleted file, across the rename), and
otherwise just keep the new file (as renamed) as happens today? That
will preserve ancestry at least--is some other history potentially lost?

I think I'll start on this. Based on feedback here I'll probably also
run this by the svnmerge.py or dev mailing list for further critiquing.
If an organization can standardize on svnmerge.py for all merges, then
there's no need to wrap other clients (just don't use them for merging
yet), and maybe we would have a reliable workaround for the rename
problem--unless I'm missing something else.




To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 12 18:09:04 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.