[PD-dev] CVS to SVN ?

Hans-Christoph Steiner hans at eds.org
Fri Dec 21 02:19:59 CET 2007


On Dec 20, 2007, at 5:06 AM, Winfried Ritsch wrote:

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

We talked about this at PdCon and everyone was willing to make the  
switch.  There is a list of people, the SourceForge members list, we  
can just ask everyone. On that list.  That will be MUCH less work  
than a multi-stage transition.

.hc



>
>> 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/)
> --
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


------------------------------------------------------------------------ 
----

Access to computers should be unlimited and total.  - the hacker ethic






More information about the Pd-dev mailing list