Re: CVS -> SVN -> Git

Karl Fogel wrote:
> I think an intermediate interchange format is the right
way to go.
> 
> But, isn't this what VCP / RevML is all about?  Perhaps
RevML is
> already suited to be that interchange format...
(Haven't looked at it
> in detail, just pointing out that there has at least
been an attempt
> to reinvent this wheel already  ).

Thanks for pointing out that project; I wasn't aware of it.

A very cursory glance over their website is not promising. 
According to
ht
tp://public.perforce.com/public/revml/index.html,
"This open source
project is no longer under active development.".  And
according to the
README,

> 3) Major features
>
> The most major feature on the TODO list is branching. 
It's still on
> the TODO list because it's hard to map between the
various branching
> metaphors, or other metaphors (like bitkeeper's LODs)
out there.

And the mailing list has had very little traffic in the last
couple of
years.

Actually, I'm not sure that a serialized intermediate format
is
required; the Python data structures and databases used by
cvs2svn now
could probably be made flexible enough, at least for output
back ends
that are written in Python.

Michael

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Michael Haggerty <mhaggeralum.mit.edu> writes:
> A very cursory glance over their website is not
promising.  According to
> ht
tp://public.perforce.com/public/revml/index.html,
"This open source
> project is no longer under active development.". 
And according to the
> README,
>
>> 3) Major features
>>
>> The most major feature on the TODO list is
branching.  It's still on
>> the TODO list because it's hard to map between the
various branching
>> metaphors, or other metaphors (like bitkeeper's
LODs) out there.
>
> And the mailing list has had very little traffic in the
last couple of
> years.

Ah, okay.  So much for that .

> Actually, I'm not sure that a serialized intermediate
format is
> required; the Python data structures and databases used
by cvs2svn now
> could probably be made flexible enough, at least for
output back ends
> that are written in Python.

Well, it can be handy to stream a conversion across the
network, with
the source and destination repositories on different
machines.  That
implies a serialization format.  In cvs2svn, this is simply
the SVN
dump/load format... Hmmm, or it used to be, except the
--dump-only
option seems to have been subsumed into --dumpfile=foo, and
it's not
clear (from the docs) that "-" for foo means
stdout, or that there's
any other way to direct to stdout these days.

Er, well, so, okay: I don't know if cvs2svn still supports
that
feature, but back when it did, I used it a couple of times
and liked
it . 
It would be nice to retain at least the possibility of that
feature.  I'm not sure what that implies for VC systems that
don't
have a dump/load format; perhaps cvs2yyy itself could be
both sides,
and just serialize Pythonic data as necessary.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org