RE: [PATCH v1] Remove no-op revisions

Hi,

Oswald Buddenhagen wrote:
> such no-op revisions are sometimes created intentionally to
> "amend" a borked commit message of a previous commit.

This could be done better with "cvs admin -m", but that
requires more permissions in the CVS repository.  So I can
see why people would use "cvs commit -f" for that.

> in such a situation, replacing the earlier commit's message
> would be most appropriate.  however, detecting such a
> situation could be done heristically at best.

I agree that a smarter choice of commit message would be good,
or perhaps even concatenating the two commit messages.  However,
I think this could be done as a later improvement.

> 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).
They've then had further commits, so the fact that 1.1.2 was a
vendor branch has been lost.

The branch layout looks like this:

  1.1 -------------- 1.2 --- TRUNK (1)
    \
     \--- 1.1.2.1 ---------- FOO-BR (1.1.2) (old vendor br)
             \
              \------------- IMPORTANT-BR (1.1.2.1.1)

(Lets see if ASCII art survives the corporate mail system...)

The branch name FOO-BR is used elsewhere as a real branch.
And for non-technical reasons too boring to go into here,
I don't want to convert FOO-BR from CVS to SVN.  I do need
to convert IMPORTANT-BR.  But cvs2svn sees that IMPORTANT-BR
depends on FOO-BR, so I have to convert both or neither.

When CVS does an import, it creates rev 1.1 with the file contents
and an "Initial import" log message, then it creates the branch
revision with the real log message and an empty diff.  My patch
detects that 1.1.2.1 has an empty diff, and correctly fixes the
branch layout:

     /---------------------- IMPORTANT-BR (1.1.2.1.1)
    /
  1.1 -------- 1.2 --------- TRUNK (1)
    \
     \---------------------- FOO-BR (1.1.2)

IMPORTANT-BR was actually created by branching trunk, so this
matches what we expect.  And we can exclude FOO-BR and keep
IMPORTANT-BR.


So perhaps a better approach would be to detect specifically
the import situation?  I.e. if the log message of rev 1.1 is
"Initial Import", rev 1.2 (or later trunk rev) exists, and
there's a rev 1.1.X.1 which has an empty diff from rev 1.1.
In this case, perhaps we can guess that 1.1.X was a vendor
branch with a non-standard branch number.  If we did that,
then cvs2svn's normal vendor branch handling would give us:

     /---------------------- IMPORTANT-BR (1.1.2.1.1)
    /
  1.1.2.1(ntdb) ------------ FOO-BR (1.1.2) (vendor br)
    \
     \-------- 1.2 --------- TRUNK (1)

and thanks to the magic of vendor branches, I can exclude
the FOO-BR vendor branch whilst keeping IMPORTANT-BR.

Would this be preferable?

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=2456488

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