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

On 01/21/2011 01:14 PM, Anders Pilegaard wrote:
> On Sun, Jan 9, 2011 at 9: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
>>> -------------------------------------------------------------
> [...]
>> Just a not of caution: even in the case that a "before" and "after" tag
>> pair can each be successfully expanded across the repository does not
>> ensure that diff(before -> after) == diff(before_expanded ->
>> after_expanded) [...]
> 
> I noticed this happening in our own tests - and it is a serious
> problem for us since we reallyl want to preserve the "diff" property
> of before/after tags.
> 
> 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.

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.

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.

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

Michael

-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

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

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