that they are relevant for a completely unrelated field. But that's my personal point of view, and I certainly do not want to say that darcs is a bad system just because of this kind of "advertisement".
Well I _think_ its just set theory. But I'm stepping out of my area of expertise so I'll not try generalize further.
If I understood git correctly, it doesn't store any patches but always the full versions of the files and the state of the tree, identified by some hash. On the other hand, it seems like darcs really stores the patches themselves. I hope, it stores a copy of the last version, as well, otherwise I'd certainly not entrust my data to it.
Arg.. I seem to have jumbled up my statements. I was also trying to work in the concept of mutiple tree distributed stuff and peer related facilities of arch and git but I botched it. Sorry. Too much caffeine when I wrote that.
something like darcs, is that when it comes to version-control systems, I prefer to be pretty mainstream. The reason for this simple is that I want to have such a system being maintained even after a few years. Advanced features like the support for sophisticated branching and merging algorithms or methodologies are really secondary for me. That's why I always had in mind to use Subversion for a new project.
Can't argue with that. My biggest beef with svn is the way the repository is versioned. Its not suited well for mutiple unrelated projects. My eval of svn was centered around my professional work as an embedded developer and software manager. Where our CVS repo has dozens of different projects all in seperate modules.
Now unless I totally missed something with svn if I wan't to maintain a seperate version number for each of those projects I have to have seperate repositorys. Setting up a repo requires admin access. So I have to either give admin access to my other developers or they have me do it when they want a new module. (Or I guess I could make some sort of automated web) . But its just a pain.
Darcs has been allmost a drop in CVS replacement and overall really fits in with the way my developer team likes to work. In fact better than CVS did. No central repository is really nice.
I'm sure svn will work great for pyTone though and I look forward to learning a bit more about its use "in the wild"