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]].