Slashdot Mirror

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

Hooks are client-side-only. Since arch doesn't count on a particular storage backend or access method, it means you can't write hooks that force, for example, certain tests, or does notifications, upon commit or other actions on the tree. I think this is a more serious weakness; but to fix it might mean giving up the advantages of a server-free implementation.

The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.

One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.

But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.

An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.

At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.

I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.

The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.

One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.

But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.

An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.

At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.

I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.

The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.

One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.

But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.

An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.

At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.

I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.

The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.

One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.

But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.

An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.

At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.

I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.

Mmm. There's a better one; see here for a presentation by Colin Walters (a Red Hat employee) on GNU Arch.

Incidentally, Arch is where SVK got its star-merge algorithm.

I have a largish tree that's in dire need of some revision control. If things go as planned, it will be developed in multiple branches and will have automated remote checkouts (maybe even automated unit testing).

You might like Rhythmbox a bit better than GQmpeg or xmms but it depends how you weight your different needs. It doesn't look like ass and it has neat metadata but 1. no viz, 2. no ID3 editing, and 3, no moon on a stick.

This is assuming a gtk2 app is acceptable, you can get it running-without-crashing for enough time to build up useful playlists and use it enough to make the metadata actually have an effect.

If you can't, there was a fork/branch a while back that add's streaming management and is relatively stable.

For the id3 tags, I highly highly recommend EasyTAG.

Non Sequitur \Non seq"ui*tur\ [L., it does not follow]
n 1: a reply that has no relevance to what preceded it

AutoGoogle
AutoSlashBack
AutoEverything
Who?