![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
Interview: David Roundy of Darcs Revision Control 173
comforteagle writes "In the aftermath of our last interview with Tom Lord, regardless of personalities, it became apparent that the idea of decentralizing CVS is a big deal. Many mentioned darcs as an alternative to Arch. Mark Stosberg has interviewed project head-hancho David Roundy about darcs, his 'theory of patches,' what's next, and on using Haskell for the project."
Mature RCS? (Score:2, Offtopic)
Self-hosting (Score:4, Informative)
For pilot-testing a migration to Darcs, there are scripts available that convert other repository formats (Subversion, CVS, possibly others) into Darcs (and back, actually), so you avoid losing history when making the transition.
Re:Mature RCS? (Score:2)
Re:Mature RCS? (Score:3, Informative)
The hard part of writing an RCS is dealing with all those users who do things you never would have thought of, uncovering all sorts of interesting bugs.
Haskell just won't cut it (Score:2, Insightful)
Re:Haskell just won't cut it (Score:5, Insightful)
Re:Haskell just won't cut it (Score:5, Interesting)
Re:Haskell just won't cut it (Score:5, Informative)
It's a small group, but if you've the only game in town (in terms of OSS projects for them to work with)... well, that works out pretty well for you!
No, if Darcs has any major issues, it's the RAM and CPU time requirements, some of which the design makes inherently unresolvable.
Re:Haskell just won't cut it (Score:2)
I learn languages because it's impossible to respond to zealots talking about their language of choice otherwise. It usually works pretty well because zealots of languages nobody knows tend to be used to pontificating at people that don't know anything about the language in question. They're not used to people that can r
Re:Haskell just won't cut it (Score:5, Interesting)
While I don't disagree with this, there are some counter-arguments too:
Knowing a language also means knowing what kinds of changes are painful and what kinds of changes are not. Knowing this in advance helps you write your programs to be more future-proof.
Re:Haskell just won't cut it (Score:2)
That wasn't the cause. Naturally, this claim is completely impossible to back up without a protracted debate that would require me to post code. I'm not up for that, so I'm just going to leave this here.
"Much the same problem can happen in imperative languages, only the class of changes which would trigger such a restructure are different. For example, in a non-GC'd language, you may end
Re:Haskell just won't cut it (Score:2)
Right, hence I said it "may" be the cause. :-)
Having said that, your code still might not have been as ideomatic as it could be. For example, what was originally just IO could end up as a huge stack of monad transformers by the time you're done. Making a type synonym for the monad in the first place saves you a lot of hassle down the track.
I say this from bitter experience. There is many a time when I've had to thread something through a l
Re:Haskell just won't cut it (Score:2)
This is why I think Boo [codehaus.org] is so damn nifty. It's statically typed, but will infer types if possible (unless the user decides to use the optional explicit typing), and also allows duck typing [codehaus.org] to just resolve everything at runtime Python-style.
Re:Haskell just won't cut it (Score:2)
In Python, programs don't tend to involve the degree of recursion that they do in Haskell. Also, it tends to be flatter than Java (eg, you don't end up with subclasses five deep of an abstract class implmenenting some interface), largely because of the dynamic typing and dynamic binding, Ty
Re:Haskell just won't cut it (Score:2)
I meant what I said.
Re:Haskell just won't cut it (Score:2)
Actually, that previous reply was a little dismissive. Let me explain.
If you write what is basically C code in Haskell, you will end up with maintenance difficulties. A small change may well result in a large restructure. You need to write Haskell code in Haskell (although ML code or Lisp code might also do if you're clever).
Re:Haskell just won't cut it (Score:2)
" You need to write Haskell code in Haskell (although ML code or Lisp code might also do if you're clever)."
I've said exactly the same thing (the phrase "write X in X") about a) Paul Graham's comparison of Lisp to Python and b) the average C++ programmer's attempts to write anything in anything else. Probably at other times as well, but I don't remember.
I currently know 12 languages[1], and while I'm not a master at all of them, I always do my best to learn to write X in X. This has made me a better
footnote -- whoops (Score:2)
1- C, C++, Objective C, Java, Python, {SPARC, x86} assembly, LISP, Haskell, Prolog, Pascal, VB (blearghhh), shell
Re:Haskell just won't cut it (Score:2)
nested conditionals, well yes, you should use case statements anyway. But then I program in C like a functional programmer anyway to a large extent. Everyone should learn a functional language, just to help you think about things in different ways. And Haskell does have the best type system of any language I have used.
Re:Haskell just won't cut it (Score:2)
Not chained. Nested.
case statements can be useful in preventing chained conditionals if you're looking at a single value, but they can't really help with nested conditionals.
Re:Haskell just won't cut it (Score:2, Insightful)
I have to say that I am troubled by this kind of attitude, especially on Slashdot. True, open source is mostly about freedom, but it is also about diversity, about innovation, and about trying to do things the right way. Since when do we condemn a project to failure just because it makes a non-mainstream choice, even if the choice was preferred by the developers due to technical superiority?
How do you feel when PHB
Who cares? (Score:2)
However, neither of the above apply. This is basically a hobbyist project, a rare and rarified subject in both its spheres (version control and Haskell), with considerable overlap between the academic C.S. community that truly understands either.
"People won't learn a language for one program"? Not even if that program is on
Re:Haskell just won't cut it (Score:2)
Re:Haskell just won't cut it (Score:2)
One word: elisp. And thus do I disprove thine assertion:-)
People will learn a language specifically to use a tool, provided that the cost of learning is less than the value added thereby.
Re:Haskell just won't cut it (Score:3, Interesting)
I'm not the grandparent poster. I am a long-time Haskell user, though.
Saying that Haskell is "all over industry" is a gross exaggeration. Anecdotal evidence from Haskell users is that they are all over industry, and they tend to use Haskell in their work, though not necessarily in code that other people see. I, for example, have been known to prototype algorithms in Haskell and then translate them into C++ for our product.
Having said that, there are several consultants out there who write custom apps f
Re:Haskell just won't cut it (Score:2, Funny)
http://www.cis.upenn.edu/proj/plclub/contest/re
You don't need as many programmers when you have this kind of tool in your hands.
Re:Haskell just won't cut it (Score:3, Insightful)
Just like how nobody uses CVSup because it's written in Modula-3, right?
Re:Haskell just won't cut it (Score:5, Insightful)
How will the choice of language hurt darcs's use? Why on earth would the users of a piece of software care about the language it's written in?
You wrote:
From the article:
So perhaps you should attempt to assimilate some facts before trotting out your tedious, ill-informed prejudices, hmmm?
Furthermore, it's not just about the sheer number of developers, it's about the power of the language. A million monkeys writing code are still only monkeys, and the more developers you have on a project, the more co-ordination is required (read Fred Brooks' The Mythical Man-Month if you don't believe me).
If "number of potential developers" were the only criterion for choosing a project's programming language, everything would be written in BASIC. And Paul Graham makes a good case [paulgraham.com] for coding in less common languages: you'll get people smart enough to learn unusual languages for the hell of it, rather than a mass of monkeys who have little interest in building great software and just want to learn this week's marketable language to improve their employment prospects.
Re:Haskell just won't cut it (Score:3, Insightful)
If your users are FOSS developers, they quite likely care about the ability to modify the tool, which includes caring about the languate in which it is written.
Re:Haskell just won't cut it (Score:4, Interesting)
you: If your users are FOSS developers, they quite likely care about the ability to modify the tool, which includes caring about the languate in which it is written.
Interesting point. Certainly FOSS developers care about being legally allowed to modify code, but I'm not sure that they care, on the whole, about the language.
emacs, for example, is largely written in elisp -- hardly a mainstream language. Yet it's extremely popular, even among people who don't know any lisp. People who find the need to extend it get a good excuse to learn lisp in a well-motivated, incremental way.
Speaking personally, I'd be ''more'' inclined to hack on a project written in something interesting like Haskell, ML, Smalltalk, or Lisp. (In fact I chose my current main project partly as an excuse to learn Lisp.) A lot of people like having a motivation for learning a new language, or a practical use for an "academic" language they happen to know. (I learned Haskell in university, so I'd be quite keen to get to use it in the "real world".)
I think the only time I'd care about the language of a program I'm using would be if it were written in something particularly horrible -- "urgh, if I ever want to modify this I'll have to learn befunge!" But perhaps that's the way some people view Haskell
It's a matter of taste, I suppose. I do acknowledge that I'm a bit of a language nut.
I still maintain that quality is more important than quantity, though. I've been teaching C and Java to second-year undergraduates this year -- having seen some of their code, I can safely say that if I were starting an OSS project, I'd rather have one seasoned Haskell hacker on board than the entire lot of 'em
Re:Haskell just won't cut it (Score:2, Redundant)
How would you feel if Microsoft released the source code to MS Excel in, say, Brainf*ck [muppetlabs.com]?
Actually, lets say its an obscure compiled language that can't be easily translated into another language at all.
Would you be praising MS for their contribution to the community or decrying their choice of language which limits the legibility and review
Re:Haskell just won't cut it (Score:2)
Then it wouldn't be free software: they didn't write it in brainfuck, so a brainfuck release is not a source code release. You could never develop an Excel-sized application in brainfuck.
I think I addressed your point in my post when I wrote:
I think the only time I'd care about the language of a program I'm using would be if it were written in something particularly horribl
Re:Haskell just won't cut it (Score:2)
Mine (1998-2001) covered, to varying extents, Haskell, Oberon, CAML, Prolog, C++, Java, MIPS assembler, and CSP. So I at least came away with a feeling of "if I ever need to use <language>, I'll just pick it up".
AFAIK my current university doesn't teach any non-imperative languages (unless you count SQL), though I'm using Lisp for a postgrad project.
I think Scheme still gets taught quite a lot, though I don't really know to what extent. I have a horr
Re:Haskell just won't cut it (Score:2)
Re:Haskell just won't cut it (Score:2)
I call bullshit. First, the language that a product is written in doesn't hurt use -- it only affects the development process.
Secondly, what's in a language? I didn't know Haskell until I started looking at Darcs; now I know a bit of Haskell, and soon I hope to be proficient enough to contribute.
There's something to be said for language agnosticism. Hask
it cuts it just fine (Score:2)
Furthermore, darcs doesn't need a "large group of developers", both because it's not a huge system and because it's written in Haskell. Being writ
Re:Haskell just won't cut it (Score:2)
CVS-style development with darcs (Score:4, Informative)
Darcs is KISS (Score:5, Informative)
Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion. Let's see:
You now have a Darcs repository! Let's do something with it:
Now your repository contains all your files. Let's look at the changelog:
Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:
We now have a repository on Jane's box. Let's make a modification:
This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)
Now let's commit and push the changes back to John's repository:
Now we can go back to John's machine and look:
(Note how Darcs generates a GNU-style changelog for you automatically.)
Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.
Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.
Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.
This system has several extremely useful effects:
Re:Darcs is KISS (Score:2, Interesting)
Subversion:
# Create a local respitory & add files.
svnadmin create
svn import * file://path/to/repository
I'm really not quite sure how that qualifies as "can't be set up in minutes". Easily as fast as darcs, and very simple.
The distributed features are what make darcs unique.. it doesn't seem to me to be any fundamentally ea
Re:Darcs is KISS (Score:2)
Subversion seems similarly easy to get started with, but what about repository sharing? To let other people access your repository, you must set up a server of some kind, be it WebDAV, or svnserve -- although I'm sure Subversion must support something like an "ssh://" protocol.
Re:Darcs is KISS (Score:3)
will check out a repository, tunnelled over ssh. No need to run a subversion server to do that.
One of the nice things about subversion (recently converted user, very happy so far) is the support for multiple url formats and communications methods.
Another notable thing (for windows users) is TortoiseSVN, (an explorer shell extension) which is just great.
I can see how the distributed, multi-repo model of bitkeeper/darcs/arch is superior but svn looks good i
Re:Darcs is KISS (Score:5, Interesting)
Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)
Tortoise is quite nice indeed -- I used TortoiseCVS for years.
Need is just one aspect of the development process; right now CVS gives most people what they need, despite the cracks in the lacquer. Darcs doesn't just erase the cracks, but improves the process.
For example, I occasionally submit patches to certain open-source projects. The easiest way to do this is to check out the CVS repository, make my changes, and do "cvs diff -u" to get the patches in that format, which I tend post to some Bugzilla server or email to somebody. But I can't commit them. I don't mean to the master repository -- I mean locally. There's no way I can bundle my file patches in a changeset and keep its history. I'm basically managing a CVS working directory where my changes are never checked in.
With Darcs, I just do "darcs get" to get the master repository, make my changes, commit them locally. I can use "darcs send" to submit my changes to the project maintainer. Anyone else can grab my patches with "darcs get" or "darcs pull". I can be Alan Cox to some Linus without breaking my back over patch management.
Re:Darcs is KISS (Score:3, Informative)
Sorry, but we were talking about simplicity here. Apache 2.0, SSL, authentication, WebDAV... Setting up a repository with what you suggest is more than one step -- it's usually a lot of steps, especially considering Subversion's external dependencies.
Setting up a Darcs repository consists of doing this:
And Darcs works over SSH:
This g
Re:Darcs is KISS (Score:2, Informative)
You can run Subversion using the svnserve tool as well. To start the server:
svnserve -d -c /repo
To access it:
svn co svn://somehostname
or with ssh
svn co svn+ssh://somehostname
Re:Darcs is KISS (Score:2)
Hardly, as it is the defining feature of BitKeeper and GNU Arch. It's a very good idea, however.
Re:Darcs is KISS (Score:2)
Perfect sales pitch! I'll have to "check it out" now, guess I should say "whatsnew it" instead!
Re:Darcs is KISS (Score:2)
So, what's the difference between Arch and Darcs?
Here: (Score:3, Informative)
Major differences:
Re:Here: (Score:2)
Huh? (Score:2)
Disclaimer: I'm currently using Arch for all my repos, but that's mainly because Haskell is not really supported properly on my architecture (by my distro). Yet.
Re:Huh? (Score:2)
2) File and Directories Copies (big feature!)
3) Repository Permissions
4) Ability to Work only on One Directory of the Repository (svn is much more flexible in this regard)
5) Availability of Graphical User-Interfaces.
the cvs-ish syntax is also a plus.
Re:Huh? (Score:2)
How does this affect users?
It's a big feature because it underlies Darcs' branching support. Darcs doesn't have a command to copy something within the repository; rather, you copy the entire repository.
Do you use them? Most people don't, as far as I know.
Agreed.
Re:Huh? (Score:2)
svn init -- cvs init
svn checkout -- cvs checkout
svn update -- cvs update
svn commit -- cvs commit
svn diff -- cvs diff
svn log -- cvs log
its nice to have the same syntax, especially when youre working on multiple opensource projects using a mix of cvs and svn. (where the repositories arent under your control, youre just a developer)
Uhm. (Score:2)
Only if the semantics are the same. If the semantics differ (subtly) it's not a good thing. Besides, you still haven't shown your original claim (that svn is strictly superior to darcs). Yes, svn is superior to darcs in some ways, but darcs is also superior to svn in some regards.
Re:Here: (Score:4, Interesting)
Support for signing patches and archives
Allows to verify who created/commited the patches. Allows to verify the integrity of a repository in case of compromise.
* Arch: Excellent. Each patch can be signed, repositories can be fully verified.
* Darcs: Incomplete. Patches sent by email can be signed so the recipient can verify the identity of the submitter. No support for verifying repository integrity. [1]
* Subversion: N/A
[1] Problem is: You can only sign something that will not vary once distributed, Darcs patches vary once distributed.
Mostly agreed, but (Score:2)
Re:Mostly agreed, but (Score:2)
Re:Mostly agreed, but (Score:3, Informative)
There is an idea, a repository of patch bundles, which could allow signed patches to be kept, at the cost of either duplication of information or inefficiency. It would "just need to be implemented." It would be a bit tedious, but is simple enough that it could be done (terribly inefficiently) usi
Re:Darcs is KISS (Score:2)
Re:Darcs is KISS (Score:2)
Not quite. Arch isn't simple to use.
From the perspective of a Darcs user:
Darcs is much simpler to use.
Darcs doesn't have branches, because every repository is conceptually a branch.
Darcs' patch format is just text (Arch uses a tarball).
Darcs has no notion of persistent file identity (which I consider a plus).
Darc
Re:Darcs is KISS (Score:2)
john@somewhere$ mkdir RCS
You now have an RCS repository! Let's do something with it:
john@somewhere$ ci -u -t-FirstPost *
Now your repository contains all your files.
Oh, wait, rcs is old and uncool...
Re:Darcs is KISS (Score:2)
If you had tried to duplicate the other steps in my little tutorial, you would have seen why RCS doesn't cut it. RCS isn't a distributed system.
Re:Darcs is KISS (Score:2)
If you want either a centralized, or a distributed system, then use CVS - there is even a version of CVS that works via email. If you want a simple system, then use RCS. If you want a wide choice of client programs, then use CVS. Note that RCS is contained in CVS.
I'm not a CVS fanatic, not at all, but I am seeing many people recreating the features of CVS with great effort, while all they really need is a better client.
The CVS server doesn't matter, it works, it is debugged, it is reliable, there reall
Re:How does Darcs handle patches by email? (Score:2)
No. The receiver end is you and your email program. You accept patches by piping the patch to "darcs apply". You reject patches by doing nothing (or replying with a rejection note). Writing a macro in Mutt og Emacs or whatever should be trivial.
You pull selectively by patch name: "darcs -p regexp".
Its the clients and API that matter (Score:3, Informative)
Interesting app. non-troll questions (Score:3, Interesting)
right away just for my own work.
Took a brief look at the pretty site. Personally I've been intrigued by Haskell for a while though never jumped in, and I use Perl. My questions:
1. Can the elegant quantum reality inspired code be separated off? Though my take is that it is already separate, as a Haskell function.. the reason for the question is that it sounds like it would be useful for a whole lot of things. Instead of implementing app/protocol X over darcs, I am wondering if you could include an (inline) Haskell module in a Perl app that would do the rest.
1.5
2. Next question, can Haskell be embedded inline in Perl code?
3. Can the quantum theory of patches be implemented as a Perl module, and ignoring the probably truth that anything not Haskell will not be as elegant as Haskell, would such an implementation benefit/be renedered possible by using the Perl functional or Quantum:: modules?
3.5 At risk of a flame war I'd love to use this in XEmacs. Anybody? This post written in vim so no flames please!
4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?
5. Time to learn Haskell!! Great!
Re:Interesting app. non-troll questions (Score:3, Interesting)
Not that I'm aware. However, all you need is an embeddable Haskell interpreter. I believe this is possible with Hugs [haskell.org], which has a "server interface [haskell.org]", and possibly even with ghc [haskell.org] (the native compiler that Darcs is compiled with). You'd probably have to write the C/Perl interface yourself.
Re:Interesting app. non-troll questions (Score:2)
This may be useful [scannedinavian.org]
Re:Interesting app. non-troll questions (Score:2)
I don't know why they have marked my last two serious questions in threads as trolls, especially when I say this is not a troll. Is there a filter that makes everyone who says that a troll?? Sheesh. Of course if this reply is marked as a troll too then we know..
Re:Interesting app. non-troll questions (Score:5, Informative)
1.5 I've thought about creating a C library for manipulating/querying darcs repositories, but haven't gotten around to it. The hard part would be of course designing the API. Ideally I'd like the interface to be such that programs using the library couldn't accidentally corrupt the repository.
2. Darcs requires ghc, since it uses some library code only available in ghc to do more efficient IO, string manipulation and to access zlib. It turns out to be a pain on many systems to link with the necesary libaries when using the interpereted version of ghc. So probably accessing darcs from perl will have to go through the executable until a C library is written (which could of course have perl bindings).
3. Rewriting darcs in perl (or parts of it) would be possible, but would be a pain. In particular, the commutation of patches which have conflicts is pretty complicated.
Re:Interesting app. non-troll questions (Score:2)
I'll definitely study the wiki. I'm interested in using darcs as darcs, and also in the theory and how it came out of quantum reality concepts. I'm not about to write darcs in perl, but was intrigued with the possibility of accessing the theory side in perl for other applications than strictly controlling patches of source code for developers. Probably it would be more helpful to learn about how you came up with the theory itself than to actually try to implemen
Needs wider adoption (Score:5, Interesting)
Not that I blame darcs or anything, just that one need to be sure that darcs work for everyone before commiting to it. CVS works on all platforms and is well tested. Darcs will hopefully get there.
And yes, I did my part and created a package for my platform. It's linked from the binary download page.
Re:Needs wider adoption (Score:2, Insightful)
CVS doesn't have atomic check-in, it's directory handling is crap, etc. etc. Still, like you said, it's probably still the best bet if you want to do development on both UNIX and Win32, although Subversion(!) is catching up fast.
Choose the development tool you prefer (Score:2, Insightful)
If someone told you to use <Tool X> for a project, you would say, "No way, <Tool Y> is more suitable for this job, and it's what I want to use." (substitute X and Y with whatever - C/Java/Perl/VB - you want).
I think David chose what he felt was the best tool for the job, taking the problem-to-solve and his own expertise into consideration. In the lig
Our experience CVS vs. DARCs (Score:5, Informative)
Darcs looked like the best choice. We converted and imported some of our archives. Then we tried checking them out. With CVS, 2-3 minutes. With darcs, 30 minutes.
Our conclusion: darcs is not scalable. Admittedly our code base is large and has a huge history, but in order to use darcs we would have had to break our projects into many small pieces, each with their own repository.
Darcs looks good. But it needs to be made much, much faster if it's to work with large projects.
If you're currently using CVS... (Score:3, Interesting)
Our current repo is 9 gigs and works beautifully.
Re:Our experience CVS vs. DARCs (Score:2)
Re:Our experience CVS vs. DARCs (Score:2)
Re:Our experience CVS vs. DARCs (Score:2)
In the case of Darcs it can be said a bit stronger as Darcs relies on GHC (the Glorious Glascow Haskell Compiler) which doesn't even have an interpreter. The interactive command line of ghc (ghci) is really just an compile-then-immediately-execute line by line interactive environment.
That's not to say that Haskell is necessarily blazingly fast, it's somewhat difficult to compile lazy languages. If you want fast functional (as in micro benchmark fast) you should look toward
Re:Our experience CVS vs. DARCs (Score:5, Informative)
And comparing darcs get with cvs checkout really isn't fair, since darcs gives you a copy of the full history of the repository, a separate branch on which to record changes before committing them to the centralized repository, and the ability to browse the history offline.
If you want a fast get, just run optimize --checkpoint on the parent repository (assuming you've tagged recently--if not, then tag the current state first), and then use the --partial flag when running darcs get. It'll still give you more flexibility than a cvs checkout, and will be much faster.
Re:Our experience CVS vs. DARCs (Score:2)
"Darcs get (equivalent to CVS checkout) is the single least efficient command in darcs. ... And comparing darcs get with cvs checkout really isn't fair.."
You've lost me, unfortunately. Darcs does seem, in some ways, to be fantastically simple, but your explanation of how to do the real equivalent of a cvs checkout just sounds irritating.
Re:Our experience CVS vs. DARCs (Score:2)
I like having the full history, but I think that in the usual case "check out the current version in 3 minutes" is a more reasonable default than "check ou
RCS? (Score:2)
Patches applied out of order - freedom or folly? (Score:2, Interesting)
I support ClearCase/ClearQuest worldwide for a large corp. I deal with the helpdesk calls, the support, the engineering efforts the "best
Distributed vs. centralized repositories (Score:3, Informative)
But in the end I think a centralized repository is right for many (most?) projects: Why Bitkeeper Isn't Right For Free Software [mit.edu] (by Greg Hudson) was the most convincing argument to me.
Of course, you can simulate a centralized model with a distributed system (just don't use the distributed bits), but it seems like you are on your own at that point. Subversion is behind when you compare distributed features (of course), but when you compare the other features (usability, access via various method, programmatic access, etc), it's way ahead. As it would be; centralized systems are easier to think about, so they are easier to develop with and on top of.
Re:Decentralization (Score:3, Insightful)
Compared to modern revision control systems, I don't think CVS is even in the running. It's SVN (in the non-distributed camp), and Arch, Darcs and Monotone in the distributed camp... with plenty of infighting between them.
Re:Decentralization (Score:2)
When you need symlinks in the repository . When all you have for backup is a solaris machine with a tape drive , When you need a web interface to update password ... It has its Niche .
That said , I just love how easily you can setup a darcs repository (just like cvs)Re:Decentralization (Score:2)
I'd think that having version-controlled symlinks in your source trees (which Arch supports but CVS doesn't) would be a more useful feature. Why would you want this?
What's that have to do with the price of beans? Arch's archive format is actually *easier* to back up to tape because it's append-only (so you can have all changesets up to #500 on one archiv
Re:CVS (Score:3, Interesting)
Already happened (Score:2)
Re:CVS (Score:2)
Re:Theory of patches (Score:2)
Re:Theory of patches (Score:4, Insightful)
No. Darcs can, and will, apply patches out of order. From the Darcs manual [abridgegame.org]:
A distributed version control system that required all patches to be applied in order would be painful indeed to use.
Why? Are you a Subversion contributor?
Re:Theory of patches (Score:2, Funny)
Re:Theory of patches (Score:2)
Why did it being in Haskell eliminate it as a choice? What kind of anal reason is that? Surely it's irrelevant what language anything is written in, insetad what matters is how good the program is. Or do you eliminate Haskell-based apps because you are a
Re:Theory of patches (Score:2)
What should eliminate something as a choice for you is the use of a language with an un-sound and demonstrably error prone type system. You know, a language like C. But perhaps the source you maintain just isn't very important.
Re:why not improve CVS? (Score:2)
CVS is a client server system. People interface with the client. If anyone feels that CVS sucks, it is because they are using a bad client.
There are many CVS clients out there and all the issues people complain about can be fixed by finding a better/different one. With any other version control system, you are pretty much stuck with whatever kludge the project has, bacause there is only one.
Re:why not improve CVS? (Score:3, Informative)
http://subversion.tigris.org/ [tigris.org]
Re:Darcs vs Svn (Score:3, Insightful)