Re: cvs2git: One possible bug, and two other issues

Anders Pilegaard <[email protected]> Fri, 21 Jan 2011 13:24:04 +0100
Newsgroups gmane.comp.version-control.subversion.cvs2svn.devel
Message-ID <[email protected]>
On Tue, Jan 11, 2011 at 5:04 PM, Greg Ward <[email protected]> wrote:
> On Sun, Jan 9, 2011 at 3:02 AM, Michael Haggerty <[email protected]> wrote:
>> On 01/03/2011 03:48 PM, Anders Pilegaard wrote:
>>> Issue 3 - Allow selected tags to "expand" to cover more files
>>> -------------------------------------------------------------
>>> [...]
>>> In our CVS repository we normally tag bugfixes with "before" and
>>> "after" tags, to make it easier to apply them to another branch later
>>> on.  Mostly we let those tags cover the entire repository.  But
>>> sometimes - especially when the commit changes only a few files - we
>>> just tag the affected files.
>>> [...]
>>> But this was not the intention of those tags - they were meant to
>>> attach to specific commits.  And they do tag the files actually
>>> changed in the commit - just not all the files in the repository.
>>>
>>> So I added some more code to allow certain tags to pass the
>>> "is_simple_copy" test [...]
>>
>> I like this idea.  I guess that this practice is pretty common,
>> especially considering how expensive it is to make a repository-wide tag
>> in a big CVS repository.
>
> Note that I addressed this in cvs2hg with the notion of "sloppy" and
> "optional" fixup commits.  See
> http://hg.gerg.ca/cvs2svn/raw-file/tip/README.cvs2hg under "Avoiding
> fixup commits".

Thanks for the pointer!

I can see from your README that the code also allows "sloppy" fixup
for branches.  As I wrote in another mail I'm not sure they are very
useful.  For tags it makes some sense if you want to be able to fetch
the repository at a given state.  The tagged files will have exactly
the expected revision, and other files will have something not too far
away.  Even so you won't preserve the diff between two tags, as
Michael noted.

But for branches I can't so far see how to handle this without
suddenly getting changes in other files recorded as part of the branch
history?  For a branch it makes more sense with an initial fixup
removing all the non-branch files - because then the later commits on
the branch in a natural way only cover the branch files.

Best regards,
  Anders Pilegaard

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2699573

To unsubscribe from this discussion, e-mail: [[email protected]].