You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2002/12/02 21:15:32 UTC

Remote cvs2svn

In looking at cvs2svn, it appears to only work on CVS repositories
that you have a copy of.

For projects that it's not easy to get hold of to CVS repository,
it would be useful to have cvs2svn work on remote repositories
(i.e. via :pserver:).

How easy/hard would this be?  Is cvs2svn set up to easily be
expanded to handle it?

Best,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Remote cvs2svn

Posted by Brandon Ehle <az...@yahoo.com>.
> 
>
>>>>In looking at cvs2svn, it appears to only work on CVS repositories
>>>>that you have a copy of.
>>>>        
>>>>
This is really off-topic, but if anyone is looking for CVS tarballs from 
SourceForge, you can find them here.

http://cvs.sourceforge.net/cvstarballs/

I've been picking some large projects from this list and running them 
through cvs2svn for performance testing purposes.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Remote cvs2svn

Posted by John P Cavanaugh <ca...@netspan.soco.agilent.com>.
On Mon, Dec 02, 2002 at 06:31:44PM -0800, Greg Stein wrote:
> I'll strongly second Daniel's points here. cvs2svn was built entirely with
> the idea of having the ,v files available for reading.
> 
> On Mon, Dec 02, 2002 at 04:38:14PM -0500, Daniel Berlin wrote:
> > On Mon, 2 Dec 2002, Blair Zajac wrote:
> > > In looking at cvs2svn, it appears to only work on CVS repositories
> > > that you have a copy of.
> > >
> > > For projects that it's not easy to get hold of to CVS repository,
> > > it would be useful to have cvs2svn work on remote repositories
> > > (i.e. via :pserver:).
> > >
> > > How easy/hard would this be?
> >
> > Impossible.
> > Well, I guess it's not technically impossible, but it would be slower than
> > molasses and hard on the server.
> 
> No, actually I believe it *is* technically impossible. IIRC, the "cvs log"
> output does not fully detail the revision graph when branches are present.
> It isn't always possible to determine the predecessor revision in certain
> cases. And especially if somebody forces specific revision numbers -- you
> can't just say "1.(rev-1)" to figure out the predecessor.
> 
> The ,v files, on the other hand, *do* contain all of the predecessor
> information, so it can properly compute the branch graph for conversion.

I submitted a patch to cvs eons ago that added a -x (for extended) flag to 
cvs log that *will* provide this predecessor information.  Its a shame that
it never made it into the cvs tree, like several of my other patches...

Oh well.  I cant wait to just switch to subversion.


-----------------------------------------------------------------------
    John Cavanaugh                          Agilent Technologies
    R&D Program Manager                     1400 Fountaingrove Pkwy
    Wireless Network Solutions              Santa Rosa, CA 95403-1799

    Email: cavanaug@soco.agilent.com    Phone:  707-577-4780
                                                707-577-3948 (Fax)
-----------------------------------------------------------------------
       There are two major products to come out of Berkeley:  
      LSD and UNIX.   We don't believe this to be a coincidence.
                                                   -- Unknown
-----------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Remote cvs2svn

Posted by Daniel Berlin <db...@dberlin.org>.

On Mon, 2 Dec 2002, Greg Stein wrote:

> I'll strongly second Daniel's points here. cvs2svn was built entirely with
> the idea of having the ,v files available for reading.
>
> On Mon, Dec 02, 2002 at 04:38:14PM -0500, Daniel Berlin wrote:
> > On Mon, 2 Dec 2002, Blair Zajac wrote:
> > > In looking at cvs2svn, it appears to only work on CVS repositories
> > > that you have a copy of.
> > >
> > > For projects that it's not easy to get hold of to CVS repository,
> > > it would be useful to have cvs2svn work on remote repositories
> > > (i.e. via :pserver:).
> > >
> > > How easy/hard would this be?
> >
> > Impossible.
> > Well, I guess it's not technically impossible, but it would be slower than
> > molasses and hard on the server.
>
> No, actually I believe it *is* technically impossible. IIRC, the "cvs log"
> output does not fully detail the revision graph when branches are present.
Yes it does.
At least, you can get it to do so.

Try cvs log -D "30 years ago <= today" on a file.

You can build the graph in reverse from this info, since the revisions
that are the base of a branch will look like:
----------------------------
revision 1.668
date: 2002/08/14 06:36:51;  author: neil;  state: Exp;  lines: +27 -32
branches:  1.668.2;  1.668.4;
        * toplev.c (parse_options_and_default_flags): Don't call
        post_options here.
        (general_init): Initialize GC, pools and tree hash here,
        instead of lang_independent_init.
        (lang_independent_init): Rename backend_init.
        (do_compile): Call post_options hook; exit early if there
        have been errors after switch processing.
        (toplev_main): Update.



Unless i'm reading the source wrong, you will always see the log entries
for the revision that starts the branch before you see the log entries
*for* the branch, too.

> It isn't always possible to determine the predecessor revision in certain
> cases. And especially if somebody forces specific revision numbers -- you
> can't just say "1.(rev-1)" to figure out the predecessor.

No, but you can always figure out the successor explicitly if you wanted
to.

cvs log -r<revision>::, and it's the last thing it prints out.


I looked at the source to cvs between saying it was impossible, and not
technically impossible.

I'm pretty sure it isn't technically impossible, but I wouldn't want to
have to hold my breath waiting for it to finish.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Remote cvs2svn

Posted by Greg Stein <gs...@lyra.org>.
I'll strongly second Daniel's points here. cvs2svn was built entirely with
the idea of having the ,v files available for reading.

On Mon, Dec 02, 2002 at 04:38:14PM -0500, Daniel Berlin wrote:
> On Mon, 2 Dec 2002, Blair Zajac wrote:
> > In looking at cvs2svn, it appears to only work on CVS repositories
> > that you have a copy of.
> >
> > For projects that it's not easy to get hold of to CVS repository,
> > it would be useful to have cvs2svn work on remote repositories
> > (i.e. via :pserver:).
> >
> > How easy/hard would this be?
>
> Impossible.
> Well, I guess it's not technically impossible, but it would be slower than
> molasses and hard on the server.

No, actually I believe it *is* technically impossible. IIRC, the "cvs log"
output does not fully detail the revision graph when branches are present.
It isn't always possible to determine the predecessor revision in certain
cases. And especially if somebody forces specific revision numbers -- you
can't just say "1.(rev-1)" to figure out the predecessor.

The ,v files, on the other hand, *do* contain all of the predecessor
information, so it can properly compute the branch graph for conversion.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Remote cvs2svn

Posted by Daniel Berlin <db...@dberlin.org>.

On Mon, 2 Dec 2002, Blair Zajac wrote:

> In looking at cvs2svn, it appears to only work on CVS repositories
> that you have a copy of.
>
> For projects that it's not easy to get hold of to CVS repository,
> it would be useful to have cvs2svn work on remote repositories
> (i.e. via :pserver:).
>
> How easy/hard would this be?
Impossible.
Well, I guess it's not technically impossible, but it would be slower than
molasses and hard on the server.


> Is cvs2svn set up to easily be
> expanded to handle it?

cvs2svn parses the RCS files that make up the repository, to gather the
information needed for branches, etc.
It then uses the RCS commands to get the various revisions it wants,
when it wants, from that RCS file.

The second part would be easy (but slow) to do remotely, and would be very
hard on the remote server (since it would be requesting every single
revision of every single file. It would also do it in the order that will
take the longest, since it will go earliest revisions first, which, for
CVS, is the worst case).

The first part you'll have to parse out of CVS's output, and to do
correctly, requires doing things like running "cvs status -v" on the
entire repo, and parsing out the tags that each file has.
Unfun in the extreme.


 > > Best, > Blair
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org