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

On Fri, Jan 21, 2011 at 4:33 PM, Michael Haggerty <[email protected]> wrote:
> On 01/21/2011 01:14 PM, Anders Pilegaard wrote:
>> Hmm - would it be possible with reasonable effort to detect if a tag
>> has a unique expansion?  For any given tag there is in general a set
>> of commits which could correspond to this tag.  If the tag covers all
>> files in the repository the set should only have one element (since
>> any commit would change *something*).  If the tag only covers a few
>> files there is a risk that multiple commits could match the tag - and
>> that is the situation where expansion causes the tag to become
>> ambiguous.  So AFAICT it should be safe to expand the tag if there is
>> exactly one commit matching the tag?
>
> You are ignoring the fact that the concept of "commit" is not
> well-defined.  Even if a tag matches only a single SVN commit, that does
> not guarantee that it doesn't match other plausible commits that didn't
> happen to be chosen by cvs2svn.  I'm afraid that this line of attack
> will not be 100% reliable unless you teach cvs2svn to treat pairs of
> related tags specially.

Ah, well - I clearly need to think more about the theory behind these
conversions.  It's definitely not a simple task ... :-)

> For your purpose you would probably like to set TAG1 via best-guess
> autoexpansion and then set TAG2 to the equivalent of TAG1 patched with
> the diff CVS_TAG1..CVS_TAG2.  But it won't be trivial to fit this into
> the rest of the reconstructed repository the way users would expect.

Hmm - it's probably not worth the effort to get this completely right.
 Conversion is complex enough as it is - handling relations between
pairs of tags would be a lot worse ...

> Since you are converting to git, it might make sense to do some
> repository rewriting *after* the conversion.  For example, maybe we
> could make cvs2git emit each TAG itself and also emit a second
> TAG_expanded when it guesses that it is reasonable.  Then, after the
> conversion, you could check whether TAG1 and TAG2 touch exactly the same
> files, and if so generate TAG2 relative to TAG1 via the patch described
> above.  Then delete the unwanted tags.

Actually, it's not the commits themselves that bother me - it's the
fact that I have to look at them ... :-) ... A good way of making them
invisible would serve my purpose just as well.

Right now my best idea is to use the filters to eg. 'git log' to
exclude these commits.  If I change the author of manufactured commits
to something that is easy to exclude with a regexp, I can use the
'--author' filter to avoid them.  Right now I'm using
'--author="^[^c]"' - but that also excludes other authors that start
with 'c', so I need to select a better first char ... :-)

>>> - Does your patch also allow branches to be expanded, or only tags?  Is
>>> there a reason for the decision?
>>
>> I only thought about tags when I made the change.  Thinking about it
>> now I guess it would be quite dangerous to expand branches also?
>> We've always made branches cover the entire repository, so it is no
>> big issue for us.  But if a branch tag is expanded, how will we then
>> handle the commits on the branch?  Which revision should non-branch
>> files have?
>
> The case of a branch is technically the same as that of a tag as far as
> CVS is concerned.  The files that were not added to the branch will, by
> definition, never have any modifications on that branch.  So just adding
> the branch tag to the revision that you think should have been on the
> branch will cause the file to appear on all revisions on the branch with
> unchanging content.
>
> Nevertheless, it might arguably be more dangerous to autoexpand branches
> than tags, simply because branches are used differently than tags.

In our case it is very important to keep the diffs between begin/end
tags intact in the conversion, so I don't think we'll pursue
tag/branch expansion any further.  And since I would obviously need to
think some more about the details of conversion before I could really
contribute, I won't argue this further ... :-)

/Anders

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

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