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