mods: I used “git” tag. Do need a vcs tag?
As a fellow not-git enthusiast, I would like that. I really don’t like the idea of VCS to be synonymous with “git”. Monocultures stifle innovation, and there are ideas worth having that git does not have.
Now, as to the article, darcs released a new version? I wasn’t even aware that they were still popular enough to attract this much development! What is darcs up to nowadays? The release announcement doesn’t seem to highlight anything particularly earth-shattering. I see a bunch of little concessions to git users, apparently making the interface more git-like.
I just spent an exciting week with the Mercurial developers, and there’s so much good stuff in hg. If I see any interest, I might write a blog post summarising what I saw.
I think a blog post would be a really good idea, honestly. Few developers are aware of the scaling efforts going on in Mercurial right now, and I think that’s a damn shame. I’m also not keen on the SCM monoculture we seem to be developing; publicizing why the alternatives matter is really important.
A vcs tag would be great. Git is the present of vcs; it shouldn’t have to be the future as well. :)
Huh. Neat! I still really like that darcs patches commute; it makes merges so much easier compared to the git model… I don’t feel this margin has space to summarize the issue, sorry. :)
That said, git does what it does for an excellent reason - tamper-evident history is a security feature.
I’ve used both extensively, and I really miss the great Darcs UX. I’m hopeful that someday GitHub will endorse a vcs that isn’t git; I don’t see how else we can ever get away from it. :)
The VCS of future will have to import .git repos out of the box, otherwise, it won’t be the VCS of the future ;).
I don’t think it’s really about security as such; it’d be easy enough to add signatures to a Darcs-like system and have stronger security than Git or Mercurial. (You’d end up with something that looked like Monotone claims.)
The bigger problem with Darcs is that it doesn’t actually quite work. If, in patch P1, I rename Foo to Bar, and in patch P2, you add new code using Foo, then Darcs will (IIRC) be happy to apply them in either order, but you won’t actually end up with valid code together. This is exactly why Git, Mercurial, Monotone, and others have merge commits.
(That said, I’d swear Darcs used to have the ability to have a “patch” actually be what amounted to a sed command to run against the repository, but I sure can’t find it anymore. I was going to comment how it’d help alleviate that type of issue.)
Actually, for the reason that patches are self-contained and don’t encode the previous node in the branch, per-commit-signing in Darcs is possible even with cherry-picking without breaking the integrity of the patch.
Darcs does have merges and it works. For your example: both directions (remote rename -> local change or local rename -> remote change) will end up as a merge conflict, making a merge patch necessary. Both patches will still be applied in the history, but cannot be both applied to a repos without the corresponding merge patch.
That said, I’d swear Darcs used to have the ability to have a “patch” actually be what amounted to a sed command to run against the repository, but I sure can’t find it anymore.
Is ‘replace’ what you’re thinking of?
Aha, yes! That’s exactly what I was trying to find! That’d be really powerful if integrated into refactoring tools. I remember taking a stab at something like that for Emacs with Semantic forever ago, but I never got very far. It’d really help path commutation though.
So the thing is that in darcs, because patches get reordered during merges, the signature can only close over an individual patch. Git’s signatures close over the entire history of patches.
Darcs provides such guarantees, just not on a linear history. It can provide such guarantees for a pack of patches, for example a tag. Tags are also conceptually simple: they just depend on all previous patches being applied.
Well, that’s fair… but it means you wind up with someone having to decide, as a unit, on whether their signature means what they want it to on all the patches since the last time somebody tagged it.
In the face of history rewriting and patch changing through merges, rebases and amends, I don’t see much of a difference to git there. In Darcs, I can make everyone sign their commits, never to be changed, in git, I cannot.
Yeah, which one you actually want is a good question. :)
Point being: the history of git is not tamper-evident. Trivial operations lead to things indistinguishable from tampering. The crypto first and foremost preserves integrity.
Unless I tag, obviously, and there, both behave the same.
Well, point taken and that’s true. I think the original idea was that you are supposed to know when you are incurring that… At least history rewrites are possible! They weren’t in CVS, at least not without your own tools.