[PD-dev] CVS to SVN ?

[Winfried Ritsch]

Hello,

> > 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.
>
In an ideal world it would be good, but I think people work on their externals 
with CVS and cannot change at a date we set, so I prefer die individual 
approach.

> 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.
>
I think with cvs2svn.sh  you convert all history and it is the same as 
converting the whole thing or a subtree.



> > 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.

The same discussion like we had before ;-). I think of externals as projects 
which some developer(groups) bring in and feel responmsible for. The have 
their tagging, branching behaviour or style. The externals are not 
orthogonal, some are redundant etc so the best is to deligate them to the 
core-developer of that externals and everybody is happy.  Also delegation (in 
future) can be done much more easier. They also can decide if they want cvs 
or svn and the date they will do so.

So I think at the end of the last discussion most preferred this solution.
(For me its important to do my own tagging and branching on e.g. the 
iem-externals and dont mix up in a huge tag or branch directory, and also 
show for others what is a mostly independent library and what belongs 
togehter, especially if there are subfolders.

mfg winfried
-- 
--
- ao.Univ.Prof. DI Winfried Ritsch 
- ritsch at iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--