RE: [PATCH v1] Remove no-op revisions

Hi,

Michael Haggerty wrote:
> Jon Foster wrote:
> > Oswald Buddenhagen wrote:
> >> i don't remember whether you already said that ... why else
> >> would somebody have used commit -f and why would you want
> >> to get rid of these commits?
> > 
> > Having looked at the troublesome files some more (and having
> > learned about another way to abuse CVS), I think they were
> > actually created with "cvs import" with a branch number of 1.1.2
> > specified explicitly.  (Normally the vendor branch is 1.1.1).
> 
> Is there a way to specify the branch number that CVS should use
> for an import?  Maybe this an be done by choosing an existing
> branch name then using "cvs import -b BRANCH ..."?

Yes, "cvs import -b 1.1.2 ...".  No existing branch needed,
the -b parameter takes a numeric revision.

http://ximbiot.com/cvs/manual/cvs-1.11.23/cvs_13.html#SEC109

This is the "another way to abuse CVS" which I alluded to
earlier.  It creates a repository where you can't reliably
check out revisions by date, because CVS doesn't know that
1.1.2 was a vendor branch.

> 1.1.2 is usually a branch number that would be used for a normal
> (non-vendor) branch that sprouts from revision 1.1.

Yes.

> What is the evidence that it came from an import?  I guess
> there is:
> 
> * The incriminating 'Initial revision\n' log message on revision
> 1.1 (though that doesn't indicate *which* branch was the vendor
> branch)
> 
> * The empty delta relative to 1.1 (though this could come from a
> "commit -f")
> 
> * Are the timestamps on 1.1 and 1.1.2.1 the same?

Yes to all of the above.  And in this case, the "smoking gun"
is the fact that the ~1000 branches/tags we've created on this
file over the last 8 years are all on rev 1.1.2.1; there are
no branches/tags at all on rev 1.1 (apart from the 1.1.2
branch).  For many of these branches/tags, I know they had
trunk as a parent, not FOO-BR (branch 1.1.2).  (Some of
those tags I created myself, and I've never deliberately
used FOO-BR).  So 1.1.2 must have been the default branch
until rev 1.2 was committed.

> Could it be that there was earlier a vendor branch 1.1.1,
> but it was later "obsoleted"?

There's no rev 1.1.1.1 in the repository.  Also, revs
1.1.2.1 and 1.1 have the same timestamp.  So I think someone
misunderstood what "cvs import" does.

> All in all, this is very mysterious and quite specialized,
> so we should be careful about what we build into cvs2svn
> to handle it...

Agree.

[...]
> > The branch name FOO-BR is used elsewhere as a real branch.
> 
> This suggests that FOO-BR started its life as a non-vendor
> branch...

Heh.  If only it was that simple.  There seem to be people who
don't use "cvs add", instead they use "cvs import" to add new
files - without understanding all the magic that "cvs import"
does.  Also, in our repository, it's extremely common to have
different parents for a branch in different CVS modules;
different parents within a module is less common but does
happen.

[...]
> > So perhaps a better approach would be to detect specifically
> > the import situation?
[...]
> > Would this be preferable?
> 
> I wouldn't want standard cvs2svn with the default configuration
> to consider anything but the 1.1.1 branch to be a historical
> NTDB, because the evidence remaining in CVS for such an
> interpretation is too unreliable.  But for your particular
> purpose, you could certainly consider patching the version
> cvs2svn that you use for your conversion.

I'm trying to get all my changes merged into the official
cvs2svn (although most of them will have to be options).
This way, my changes get some code review.  I'd rather find
bugs now, rather than wait a year and then discover our SVN
history is corrupt.

So if you'd prefer the "remove no-op revisions" approach rather
than the "detect non-standard vendor branches" approach, then
that's what I'll do.

[...]
> However, I am skeptical whether this would achieve your desired
> result, since you say that FOO-BR is used as a normal branch
> in some other files.  In that case, I think cvs2svn would
> refuse to treat it as a vendor branch that can be deleted.
> But maybe your vendor branch exclusion code is not so squeamish?

I intend to exclude FOO-BR by name, so it's excluded everywhere.
(Or rather, I intend to exclude all branches by default, and
I'm not going to add FOO-BR to the list of exceptions).
I have tested this and it works.

> As for generically allowing revisions with empty deltatexts
> to be omitted, I can imagine that there are some unusual
> situations that might benefit from such an option.  But ossi's
> reminder that such revisions have separate log messages (and
> indeed might have been created *because* of the log message)
> means that the feature would be somewhat dangerous.
> 
> The idea to concatenate the log messages is a good one, but
> would only work if each and every file containing one of the
> revisions also contains the other; otherwise, one would end up
> with two or three separate commits with log messages like
> "msg1", "msg2", and "msg1 msg2" that cannot be joined together.

Yes, this would be a problem.  Just picking one of the log
messages is better.  (If the user wants to change the log
message, then at least in SVN the "svn propset" command will
allow it to be fixed manually).

> All that being said, I can imagine accepting a patch to add
> an option to omit zero-delta revisions, even though IMO the
> cost-benefit ratio is pretty close to 1.
> 
> IMHO, the real problem that underlies this whole discussion
> is our mishandling of NTDBRs when branches or tags sprout
> from them.  Ideally (assuming that FOO-BR were recognized
> as a vendor branch), cvs2svn would realize that your
> IMPORTANT-BR might have sprouted from FOO-BR *or* trunk.

I think it does work that way already?  (In cases where cvs2svn
detects the vendor branch, anyway).  In cvs_file_items.py,
LODItems::iter_blockers() seems to handle this correctly.

So.... what do I need to do to get this patch into cvs2svn?
Is it just a matter of fixing the TODO, or is there more?

Kind regards,

Jon



**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**********************************************************************


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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

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