Re[2]: [PROPOSAL] Move APR to the subversion repository

[Lev Serebryakov <le...@serebryakov.spb.ru>]

Hello, Brian!
Saturday, March 13, 2004, 5:44:27 PM, you wrote:

BWF> Please define 'better'
  50+ success stories with refinecvs (and all of these people try
  cvs2svn before). About 10 repositories I know, which COULD NOT BE
  converted with cvs2svn & converted with refinecvs. I don't know any
  repository, which is converted with cvs2svn without problems and
  could not be proceed with refinecvs. If you know such repositories
  -- you are welcome!

BWF> Last time I checked refinecvs it:
BWF> - Did the entire repository conversion in-memory.
  Yes, it is one of main `feature/bug' of this script. It works fast, but
  consume memory. Some algorithms inside is O(n^2) and even worse. For
  example, restoring tag creation history is very slow procedure. I've
  tried to store tables in DBM, but it slow down process in orders of
  magnitude.
BWF> - Skipped over branches and tags with anomalies (if you supply certain
BWF> switches--otherwise, it just errors out).  CVS repositories often have
BWF> more RCS edge cases than actual data. :-)
  Even in case of `apr'?
  
BWF> - Had no test suite.
  FreeBSD repository + whole cvs2svn test suite. Is it enough?

BWF> All of the above three things make me hesitant to trust my (let alone
BWF> the ASF's!) historical data to it.
  Ok. But why should I trust my historical data cvs2svn, if it even
  could not create proper dump for some of my repositories? We (I,
  you, other authors of cvs2svn, whole CVS and SVN systems) are not
  Donald Khuth or Dijkstra. We didn't prove our programs
  mathematically.
  
  I've started to write refinecvs when cvs2svn reports `All done'
  about my repository and `svnadmin load' reject resulting dump! After
  that I fixed 3 errors in dump by hands (adding files twice, deleting
  files twice) and, as final result, got repository with messed branches.

  In any case it is bad idea to blindly convert repo and think, that
  everything is Ok. In any case, it is good idea to check every branch
  and every tag (by checking out two working copies: from CVS and from
  svn and comparing byte-by-byte).
  
BWF> Has any of the above changed in the last month?
  No. Because here are no bugreports. And nobody, who complains about
  RCS edge cases could not answer on simple question: `How it should
  be proceed, what you want as result?'. What do you want as result when
  two revisions marked with one tag? Could you answer?

  I'm thinking about interactive mode for such cases... But refinecvs
  doesn't have ANY knobs to affect such cases! And even without
  interactive mode, refinecvs give you fine control over conversion
  process.

--
               Lev Serebryakov

Repository conversion, WAS: Re: Re[2]: [PROPOSAL] Move APR to the subversion repository

[Sander Striker <st...@apache.org>]

First off all, the repository conversion toolset is irrelevant
to this proposal.  The repository will be converted by the
Infrastructure Team (hi fitz!), and an integrity check will
be done.  If we encounter bugs in cvs2svn during the process,
those will be fixed.

And the other way around aswell.  If cvs2svn encounters an impossible
state, it will warn, and we can fix up the CVS repository.

Furthermore, over the years people have done some wonky things
directly in the filesystem, in some ASF projects, to 'preserve
history'.  I'm willing to bet that even when checking out a tree
with CVS you may end up with a broken tree.  This is all to do
with the fact CVS tracks files and not trees.

That said it becomes a bit more apparent why we _need_ knobs to
turn and buttons to push to do a conversion tweaked to fit our
needs.

Now, given this all has very little to do with APR, it would be
best to find a different forum for any followup discussion.

Thanks,

Sander

Re: Re[2]: [PROPOSAL] Move APR to the subversion repository

[Max Bowsher <ma...@ukf.net>]

Lev Serebryakov wrote:
> Hello, Brian!
> Saturday, March 13, 2004, 5:44:27 PM, you wrote:
>
>> Please define 'better'
>   50+ success stories with refinecvs (and all of these people try
>   cvs2svn before). About 10 repositories I know, which COULD NOT BE
>   converted with cvs2svn & converted with refinecvs. I don't know any
>   repository, which is converted with cvs2svn without problems and
>   could not be proceed with refinecvs. If you know such repositories
>   -- you are welcome!

Yes, cvs2svn used to be pretty buggy. It is now significantly less so, and
still improving.

>> Last time I checked refinecvs it:
>> - Did the entire repository conversion in-memory.
>   Yes, it is one of main `feature/bug' of this script. It works fast, but
>   consume memory. Some algorithms inside is O(n^2) and even worse. For
>   example, restoring tag creation history is very slow procedure. I've
>   tried to store tables in DBM, but it slow down process in orders of
>   magnitude.
>> - Skipped over branches and tags with anomalies (if you supply certain
>> switches--otherwise, it just errors out).  CVS repositories often have
>> more RCS edge cases than actual data. :-)
>   Even in case of `apr'?
>
>> - Had no test suite.
>   FreeBSD repository + whole cvs2svn test suite. Is it enough?

Where is this test suite? It doesn't seem to be in the tarball.

>> All of the above three things make me hesitant to trust my (let alone
>> the ASF's!) historical data to it.
>   Ok. But why should I trust my historical data cvs2svn, if it even
>   could not create proper dump for some of my repositories? We (I,
>   you, other authors of cvs2svn, whole CVS and SVN systems) are not
>   Donald Khuth or Dijkstra. We didn't prove our programs
>   mathematically.
>
>   I've started to write refinecvs when cvs2svn reports `All done'
>   about my repository and `svnadmin load' reject resulting dump! After
>   that I fixed 3 errors in dump by hands (adding files twice, deleting
>   files twice) and, as final result, got repository with messed branches.

You encountered bugs, OK, many of which are fixed now.

For reasons I do not fully understand, instead of helping to fix them, you
wrote a new piece of software.

The result is 2 tools each with their own advantages and disadvantages,
neither of which is strictly better than the other. Unfortunately, since one
is in Perl and the other in Python, I'm not sure there is any way to rectify
this situation.

>   In any case it is bad idea to blindly convert repo and think, that
>   everything is Ok. In any case, it is good idea to check every branch
>   and every tag (by checking out two working copies: from CVS and from
>   svn and comparing byte-by-byte).

Agree.


Max.