[PD-dev] CVS to SVN ?

[Russell Bryant]

Winfried Ritsch wrote:
> a) we start a parallel svn-tree.
> 
> with at least a two folder:
> 
>  externals
>  pd
> 
> where externals and pd come in.
> 
> b) Every "main-in-charge-projectleader/group" of a project  can move their 
> project to svn, either to ask someone to do so or doing himself.

I think it would be a bad idea to maintain any sort of parallel systems.  I
would rather see a "flag day" where everything gets moved, and the CVS
repository is shut down, or set as read-only, with a pointer over to SVN.

Also, from point b, it sounds like you intend that things should be moved over
manually.  However, the process for converting a cvs repository to svn is
automatic and will convert everything.  I think it would be a bad idea to move
anything manually, as you will lose all of the commit history, which would be
extremely unfortunate.

> c) structure:
> 
> We should use the external basefolder for all externals.
> But the naming and subtree can be changed and grouping to developing groups
> for future delegation options.
> 
> (I recommend to put the trunk, tags, branches as subfolder of  
> projects rather then have a very long list of versions 
> for each external, subexternal or else in one directory. )
> 
> "Each project should have their a trunk,branches,tags"
> 
> eg.:
> 
> pd/[trunk|branches|tags]

Yes, I would agree with this structure.

> ...
> externals/[some external name]/[trunk|branches|tags]
> ...
> 
> eg:
>  externals/iem/comport/[trunk|branches|tags
>  externals/iem/iemmatrix/[trunk|branches|tags
> ...
>  externals/zexy/[trunk|branches|tags
>  externals/grill/[newlib]/[trunk|branches|tags

However, I think that this externals structure sounds like a nightmare.
Personally, I would _much_ prefer the following simplified structure:

externals/[trunk|branches|tags]

The latter implies that there should be separate release handling for every
external.  That sounds like it would be confusing and cumbersome to deal with.
I think it makes more sense to package all of the "official" externals that are
in svn in a single package.  That isn't to say that you couldn't as a developer
check out a lower level directory from svn to work just on that section ...

Anyway, I'm brand new around here.  I think I'm getting beyond the point where
my opinion matters.  I'm just glad that the general consensus is to switch to
svn.  :)

Again, I would be happy to help do the work, but it sounds like there are those
that have been around longer that are already willing to do it.

--
Russell Bryant