Re: cvs2svn.py problem with --trunk

[kf...@collab.net]

Blair Zajac <bl...@orcaware.com> writes:
> I'm seeing some odd behavior using cvs2svn.py's --trunk:

That's the expected behavior, I think (though --trunk isn't tested
much and might well have other bugs).

The recommended repository layout is

   PROJ/trunk
       /tags
       /branches

We are taking the top level directories of the CVS repository as the
PROJects, and splicing the trunk|tags|branches underneath them.

See the function make_path() in cvs2svn.py.

-Karl

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

Re: cvs2svn.py problem with --trunk

[kf...@collab.net]

Blair Zajac <bl...@orcaware.com> writes:
> I think I see where we're both coming from.  You're looking to handle
> branches, tags and trunk.  I'm looking for a very simple command line
> saying, import path/to/dir1 from CVS into path/to/dir2 into SVN.  I
> thought trunk would specify the entire path/to/dir2, but because it is
> interjected into the result path, it actually looks just to specify
> the name of the "trunk" directory in the path, which I don't think
> many people will change, unless they choose "head".
>
> So for me, the relevance of --trunk is much reduced.
> 
> I think we need a --prefix option, where the path to the top level
> PROJ is specified.

Yup, good point!

> Some other usage notes:
> 
> 1) If you want to rename PROJ to say PROJ1, you can't do it without
>    manually moving the directory i

Or running svndumpfilter (or otherwise tweaking the dumpfile before
pass 5 of cvs2svn.py runs).  We haven't got smooth support for that
yet, though there will be options to stop/restart cvs2svn later.

> 2) Finally, with the current usage, if you have PROJa and PROJb in
> 
>    your CVS repository and you only want to import one, then there's
>    no command line usage to do that.  It'll import both.

Just run the tool on PROJa (as though it's the root of a repository).
Oh, but then the trunk|tags|branches paths won't be right.

> I think this behavior is assuming too much of the source CVS
> repository and where it should be imported into the svn repository.
> It should be up to the user to decide where to place the CVS repos
> into the svn repository.

Absolutely.

These aren't design decisions, you understand; they're just "No one's
gotten around to implementing those options, because they've been
concentrating on basic functionality."

> > We are taking the top level directories of the CVS repository as the
> > PROJects, and splicing the trunk|tags|branches underneath them.
> 
> Sounds like a bad idea, and its confusing.  First, I think its better
> to let the user explicitly decide where the source and destination
> goes.  Also, now, I have to figure out that trunk in interjected in
> the path.  I'd rather just say,
> 
>     cvs2svn.py --prefix dump/my/code/here using/code/from/here
> 
> Much easier on my already taxed brain :)

?  These two things are orthogonal, or could be...

Could you write a formal description of what you'd like to see happen?

-K

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

Re: cvs2svn.py problem with --trunk

[Blair Zajac <bl...@orcaware.com>]

kfogel@collab.net wrote:
> 
> Blair Zajac <bl...@orcaware.com> writes:
> > I'm seeing some odd behavior using cvs2svn.py's --trunk:
> 
> That's the expected behavior, I think (though --trunk isn't tested
> much and might well have other bugs).
> 
> The recommended repository layout is
> 
>    PROJ/trunk
>        /tags
>        /branches

Karl,

I think I see where we're both coming from.  You're looking to handle
branches, tags and trunk.  I'm looking for a very simple command line
saying, import path/to/dir1 from CVS into path/to/dir2 into SVN.  I
thought trunk would specify the entire path/to/dir2, but because it is
interjected into the result path, it actually looks just to specify
the name of the "trunk" directory in the path, which I don't think
many people will change, unless they choose "head".

So for me, the relevance of --trunk is much reduced.

I think we need a --prefix option, where the path to the top level
PROJ is specified.

Some other usage notes:

1) If you want to rename PROJ to say PROJ1, you can't do it without
   manually moving the directory i

2) Finally, with the current usage, if you have PROJa and PROJb in

   your CVS repository and you only want to import one, then there's
   no command line usage to do that.  It'll import both.

   I have a need for this, because we have 6 separate SVN repositories
   at work, one for each client, and there's only one CVS repository
   with different client projects mixed in it, so we're separating
   projects into separate svn repositories.

I think this behavior is assuming too much of the source CVS
repository and where it should be imported into the svn repository.
It should be up to the user to decide where to place the CVS repos
into the svn repository.

> We are taking the top level directories of the CVS repository as the
> PROJects, and splicing the trunk|tags|branches underneath them.

Sounds like a bad idea, and its confusing.  First, I think its better
to let the user explicitly decide where the source and destination
goes.  Also, now, I have to figure out that trunk in interjected in
the path.  I'd rather just say,

    cvs2svn.py --prefix dump/my/code/here using/code/from/here

Much easier on my already taxed brain :)

If cvs2svn.py doesn't imply a behavior, then we've allowed more
flexible behavior.

Best,
Blair

-- 
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

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