You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by William Uther <wi...@cse.unsw.edu.au> on 2003/04/18 05:42:23 UTC

Munging copy history (was: Re: short question about...)

On Friday, April 18, 2003, at 09:38  AM, Tom Lord wrote:

> Briefly: there isn't a reasonable (easy
> to explain/understand, user controllable, suitably flexible)
> correlation between svn's directory-changing operations and the
> programmer's idea of logical file correspondences.

[snip]

> [What you want is] directory-changing commands [that] can "do the right
> thing" most of the time, while still giving users an easy out when the
> right thing is something different.

I've been using subversion with students.  It is their first look at a 
version control system.

I often find that they copy using normal cp, remove the old '.svn' 
directories and then add things to the repository (rather than using 
'svn cp').

At the moment I have two options when this happens:

i) lose the copy history and assume that we'll never have to merge 
between the copied (or moved) data.

ii) Add the copy history in later as follows:

export their newly added stuff (call this tree A)
svn rm the newly added stuff (tree A)
svn cp the old stuff (from tree B to tree C)
check out tree C
copy the exported tree A over the checked out tree C
check in tree C.

Now we have what was in tree A back in the same location in the 
repository, but with copy history.

I was hoping that some time in the future there would be a way to fix 
this case automatically.  Some ideas:

i) My original thought was that you could use the merge history 
properties somehow, but I'm not sure the merge algorithms being 
proposed will work in this case.  Does merge history allow you to add 
new copy information, or just figure out what has been merged between 
copies that previously existed.

ii) You might be able to do something wacky with svndumpfilter that 
goes in an adds the appropriate copy history.  This is not a 
lightweight solution though...

Thoughts,

Will            :-}

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and 
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Munging copy history (was: Re: short question about...)

Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
> I often find that they copy using normal cp, remove the old '.svn'
> directories and then add things to the repository (rather than using 'svn
> cp').

MetaCVS has some support for such things.
It guesses operations by looking at inode numbers and by comparing
the textual content (using things like word-frequencies).
It of course only works in simple enough cases, but it's surprisingly
effective when doing a `mcvs import' of some vendor code and the vendor
has moved some files around in the new version.


        Stefan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org