Speaking from experience, having suffered several migrations to prcs from cvs, to svn from cvs, and to darcs from svn, in commercial projects, I have to say the only one that worked well, made sense, and was least painful was cvs-->svn, and I'd vote for that.
David On 23 Oct 2007, at 19:41, Stephen Sinclair wrote: >> are used ... beside that, i am not sure, how access to specific >> parts of >> the repository can be restricted ... > > You don't have to restrict anything. > If someone messes with your work, you simply don't merge what they > did. > They're free to do whatever they want in _their_ repository, but > you're not forced to accept it into _your_ "official" repo for your > project. > > Of course, other people would still be free to check out what the > other guy did, even if it's not officially part of the main tree. The > trick here is to think in terms of "pulling" rather than "pushing". > Since no one is pushing, no one can step on anyone else's toes. > > Anyways, I think under a system like git, the Pd kernel would have its > own repo, and other subprojects (abstraction collections, externals, > libraries) would have their own repos. A project like "Pd extended" > could then simply be a "super-repo" collecting specific repos as > submodules. Each submodule would be tagged to a specific > version/branch. > > I totally understand the hesitation, git does seem somewhat > complicated at first. Once I finally understood the whole distributed > way of thinking though, I couldn't help but dive in, and now I like > the idea so much I think I can't go back... and actually, I > discovered that the interface is really not that hard. Mostly you > just use "clone", "pull", and "commit". > > Another nice thing about it: you don't even have to "officially" > switch all at once. Someone can just start a git repo based off the > CVS, and you can go from there... whoever does that is responsible for > keeping his repo up-to-date with the CVS and vice-versa. He can check > his changes back into the CVS whenever he wants but still work with > git on his own computer. It allows for a gradual weening away from > the central repository instead of requiring everyone to switch at > once. > > I won't try any more to push the idea, but I think it's worth > considering. > > > Steve > > _______________________________________________ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev