hello,
I just missed the pdconv, so how is the authorization for the repository planed ? Is it possible to restrict access to a subfolder ?
no, since the plan is to stay with sourceforge for now, there is still no way to restrict write access to submodules (afaik).
If so I would recommend to put the trunk, tags, branches as subfolder of projects which can be deligated rather then have a very long list of versions for each external, subexternal or else in one directory. I would prefer:
so how do you like thomas grill's suggestion to do it like /trunk/pd/ /trunk/externals/iem/comport /tags/pd/pd-<x>.<y> /branches/iem/comport-<x>.<y>
its quite the same as a general trunk,branches, tags structure.
the problem with your suggestion i see is, that it is sometimes not really clear as to what is a "subproject" and what not. is it: /externals/iemlib/iemlib1/[trunk|branches|tags] or /externals/iemlib/[trunk|branches|tags]/iemlib1 ??
but this a benefit, since with this organisation everybody know which is a subproject, since developerstructure is unclear now and dependencies of libraries are encapsulated like miXed.
since it is easy to filter out trunk in path for automatic builds, this should not be a problem and everybody has freedom to organize his projects with tags and branches and subfolder before tags and branches.
well yes, as i have said before this is possible. but what is the benefit above doing it as one big project in the first place, if everybody who wants to checkout more than HEAD of pd-vanilla has to resort to setup some filtering (or use meta-projects like svn:externals)
the benefit is that its clear what is a subproject and that developer can organize their project like they want or also in respect of their internal organization, also another benefit is that with meta-project its easy to make bundles for automatic build systems add and remove projects without touch them.
and finally: cvs2svn automatically creates one big project, so everything else would be extra work :-)
thats true, but much work now is less work in the future, since the delegation is much more clear:
- Also in future when there will be (and i think it will be not to far) a possibility for individual access on folders, delegation doesnt need restructuring the repository for tags and branches.
- its easier to give access doing branches or tags for everybody in his project (release early and release often ;-).
- if a project is removed because of any reasons (legal, personal) you dont need to find all branches and tags and experimental entries, since you never know how they are named).
Its also easier to link the projects to the softwarecenter in puredata.info, as you did with Gem. "One svn place for one project." (http://puredata.info/community/projects/software)
and I saw this structure in other community projects (like plone, etc...) which seems to work.
This could be the steps for finalizing the structure (so not much more work has to be done as the other solution):
1) just do cvs2svn
2) do a branching tagging on basefolder like pd, pd-extented, ... not external with svn mv, svn cp
3) tell the poeple accessing their project they should do so if they want. Maybe some primitive external libraries, dont need it since revision numbering is enough or already finished, so just leave them without trunk, branches whatever...
mfg winfried