>> If you just write "darcs diff", you can see the changes between any two
>> versions of your repo.
>
> What if I want to use kdiff3 or gvimdiff or some other diff
> visualization tool?

Then yeah, you'd have to construct two versions of the repo, just like 
you would with any other version control system.

>> Yeah, it's unclear how you can hope to version control a binary file,
>> other
>> than just keeping a linear sequence of versions (which is what Darcs
>> apparently does). Personally I've never needed to try, but I guess
>> somebody
>> I might.
>
> Word documents. Images. Audio. Video game resources. People want version
> control for all of that.

Trying to use version control for Word documents would be a fairly 
insane thing to do. (Unless you can actually parse the binary file and 
ignore all the metadata...) But sure, I can see how if I was doing 
something other than writing text, I'd probably want to version control 
that too.

> Imagine if you were a Linux developer and people stored installation CD
> ISO images in the repository. Do you really want to check out every copy
> of every install CD just so you can fix bugs in one file system?

Man, version controlling a multi-GB ISO image sounds like a barrel of 
laughs. o_O

>>>> and doesn't even figure out which files changed.
>>>
>>> Yes it does.
>>
>> Then why do you have to manually tell it which files to commit?
>
> Because maybe you don't want to commit all your changes in one step.

So you have to manually remember what you changed? That seems rather... 
primitive. I much prefer the way Darcs does it (i.e., prompt you for 
which changes you want to include in this particular commit).

>> not sure what you mean by "Darcs needs you to do that all in one step".
>
> I mean that gathering up the changes and committing them sounds like a
> single step in Darcs.

A single interactive step, yes.

>> Damn that sounds complicated.
>
> It's very simple with the gui. You start up the gui, it shows you a
> top-left pane of files that have changed that you haven't decided to
> commit yet. Bottom right pane are files that'll be in the commit. Right
> side is the listing of the diffs for whatever file you've highlighted.
>
> If you want to put half the changes from configuration.ini in your
> commit, you click on that, go over to the list of diffs, click on each
> one you want in the commit, then click the commit button.
>
> Pretty trivial.

So Git has a GUI tool that lets you do what Darcs does natively?

>> With a centralised system, usually it's a check-in / check-out model, so
>> only one person can edit a file at once.
>
> Some systems work like that, yes, but they work
> really, really poorly when you have 200 people working on the same
> files

Presumably this is why everybody wants distributed version control now.

>> With something like Darcs, there are now 200 change-sets, each of
>> which is
>> only in some repos. Copy the change-sets around and everything is in sync
>> again. No need for complex "merge" operations or tangled file histories.
>
> Of course you need to merge them, and of course you'll have tangled file
> histories. If all 200 people change the same part of the file, you'll
> have 200 merge conflicts. If everyone is passing around partial change
> sets and making more changes that are dependent on those changes, you'll
> have a tangled file history.

Except that usually 200 people will be editing 200 different parts of 
the repository.

> Basically, you say "go look at the changes I made since I branched off
> the upstream repository, then apply those same changes to the new head
> of the upstream repository, and submit *that* as the new commit."

The Darcs model is "the bugfix for #5326 is *this* alteration". You can 
then apply that to whatever you want. (Unless the modified bit is 
altered, of course.) The Git model seems to be to do lots of extra work 
and then record it as a new item of data, which you don't actually need, 
but that's just hot Git works.

>> No, I meant it would be nice if the Darcs repo format allowed you to
>> update a repo just by copying some files.
>
> Well, git *does* store stuff in files, so technically you could copy the
> files. But by "copy files" I mean "use git to copy the new files." As
> in, "you don't have to run any diffs or patches or anything".

Oh, I see.

>> So doing things the hard way is brilliant?
>
> Building an entire type theory to discuss isomorphic idempotent change
> sets is the easy way?

After you've built it, yes. The theory is hard, but it makes using the 
tool easy.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message