Chris> OpenCM and Subversion were touted by their developers as Chris> close replacements for CVS ("only better") and also not Chris> quite ready yet. Stephen> I don't know about OpenCM, but subversion is unlikely to be better Stephen> than CVS on branching. Anything that tries to emulate CVS's file Stephen> orientation will be able to improve in areas that we historically have Stephen> not had too much trouble with (versioning directories and object Stephen> renames), but will not help much with branches (you really need Stephen> distributed repositories and history-sensitive merging to get large Stephen> benefits here). Jury is still out on whether subversion will be able Stephen> to handle history dependence or changesets well (and in any case those Stephen> are "post-1.0" features, so who knows when they will be available). I don't know what you mean by "file orientation," but Subversion does true atomic commits with global version numbering. Subversion is certainly *way* better on branches, and its branch model is completely different from CVS's. We switched to Subversion from CVS for Scheme 48 a while ago, and it's a step I often find myself being glad over. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

ms> Subversion does true atomic commits with global version ms> numbering. Stephen> Does this mean that a commit (when done judiciously, as opposed to a Stephen> MegaPatch) will automatically record the relationship among the Stephen> various files changed in a commit? I haven't looked closely at that Stephen> (that's one of your desiderata, I thought), but I've been given to Stephen> understand that although commits are atomic in the sense that my whole Stephen> commit gets done either before or after yours, file histories are kept Stephen> separately. No, there's only one linear history log for the entire repository. ms> Subversion is certainly *way* better on branches, Stephen> In what way? The features that I think we need in the medium term are Stephen> history sensitivity (where eg branches 1 and 2 both have patch A, then Stephen> if branch 1 is merged to trunk followed by branch 2, the system is Stephen> aware that patch A has been applied and does not create a spurious Stephen> conflict when branch 2 is merged), and distributed repositories (this Stephen> would be especially nice for packages, where many package maintainers Stephen> have their own respositories). Stephen> What I've seen of the list traffic at subversion seems to indicate Stephen> that these features will be postponed to "after 1.0". Stephen> That doesn't mean they're the only desirable ones, but those are the Stephen> ones I've focused on. The fundamental weakness of CVS is that branches are also per-file, which means they don't really exist in any tangible sense for the entire project. This often makes merging branches a F***ing Nightmare (TM). (And not just in theory---I've been hit by this quite often.) In Subversion, branches are just copies of a file tree at a certain revision: this means they're visible in the file-system name space. The merge database is indeed post-1.0 but, with atomic commits, it's not that difficult to keep track of what merges have been done and which ones haven't. (Which is generally impossible with CVS.) I merge branches all the time with Subversion, and it feels like Christmas every single time. I agree a merge database is desirable, but I'm sure the Subversion people will come up with the functionality in due time. The development community is active like few others I've seen. (OpenCM also looks nice, but they just don't seem to be as far along as the Subversion people.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

ms> No, there's only one linear history log for the entire ms> repository. Stephen> Are you being terse on purpose? ;-) No. Stephen> Does that allow me (or better yet, a program) to reconstruct Stephen> the relevant whole-tree patch, Yes. Stephen> or do I have to go snuffling through the ChangeLogs? No. (:-) ) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla