Re: cvs2svn - file moving

On Wed, Dec 12, 2001 at 12:25:58AM -0500, Basil James Whitehouse III wrote:
> The post about the python bindings remined me to ask this question that went
> around the office today...
>
> Often we will 'move' a file in cvs. Sometimes we do the server hack
> described in the redbean cvs book (by Karl I think) where you move the ,v
> file in the file system, so we can keep the history. Other times we'll do it
> through the client with delete and add in the new spot, commit the set and
> write an adequate comment so people can back track to get the history.
>
> I guess my question is will cvs2svn be able to figure out if files should be
> 'moved' in the subversion sense? If so, what would make it easiest so we can
> be sure to be doing it in that manner for when we make the switch (which I
> hope to be in the new year once branch merges are running).

I certainly hadn't planned to have cvs2svn try to detect a move. Never
really thought about it. That said, assuming we *do* code that at some
point, here are my thoughts:

* moving a ,v file makes it appear as if the file was *always* at that
  location. thus, cvs2svn couldn't do anything about it.

* same for copying a ,v to a new location

* that leaves "cvs add [in new loc]" followed by "cvs rm [old loc]". if
  those occur in the same commit *and* the file has the same contents, then
  we could say they are the same.

* if you make mods during the move, then there isn't anything we can do. you
  end up with heuristics of "how much change means they aren't the same
  file?" and heuristics suck on stuff like this.
  
  -> this implies that you want to move first, commit, *then* make any
     changes to reflect the new location.

Following those guides should allow us to detect and process a move.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org