On 4/21/2011 2:35, Invisible wrote:
> The Darcs workflow. I download the source code, make a small edit to it, ask
> Darcs to record that, and send the changes to the developers. They add it to
> the central repo, which checks whether the bit I just edited has changed
> since I got my copy. If not [which is quite likely], the change is added to
> the central repo. Done.

OK. All the confusions you think you're seeing in git are due to Darcs just 
not being able to do what git does.

When Darcs gets a merge conflict, it just doesn't apply *either* patch.

"Darcs escapes this problem by ignoring those parts of the patches that 
conflict."

Obviously, if Darcs isn't going to try to fix the patches for you, it's a 
lot easier to record a bunch of conflicting patches. The equivalent in git 
is to pull in changes from other repositories and then not trying to update 
your working directory to include the changes. Trivial one-liner that always 
works.

"If the conflict is with one of your not-yet-published patches, you may 
choose to amend that patch rather than creating a resolve patch."

And that's exactly what the "git merge" command does. It takes your patches, 
and someone else's patches, and merges them together. It's a separate step 
because, unlike Darcs, git supports having more than one "pristine" in the 
same repository. If you only have one branch in git, it's as trivial as only 
having one repository in Darcs.

"This is how a project with many contributors, but every contribution is 
reviewed and manually applied by the project leader, can be run." This is 
the bit about sending email you were talking about. git can work that way, 
and the terrible "merge" problems you're talking about are handled the same 
way: the guy getting the patches fixes the merge.

What Darcs apparently can't do is support any way of doing distributed 
development with an authoritative repository *without* someone dedicated to 
fixing the merge conflicts. That's where the whole rant you're talking about 
came from. If you have someone who is going to look at your changes (i.e., 
if I am CTO and I want to build a new release or something) then the whole 
"fast-forward merge with a rebase" dance is unnecessary and indeed 
counterproductive, as it loses the history of the change (in the same sense 
that unrecording a bunch of changes and re-recording one big change in Darcs 
loses the history).

I'll grant you that Darcs is definitely simpler, but I think it's less 
capable also, and that's the primary place the simplicity comes from. The 
Darcs replace command is interesting, but I'm not sure how well that would 
work in practice, especially in languages with complex scoping.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

>> 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

> Wow. Advice: Don't talk to anyone about how git works, since even if you
> think you've figured it out, you haven't.
>
>> Obviously this model cannot possibly work, so there must be something I'm
>> misunderstanding about how Git works.
>
> Ah, thank you.

Like I said, the way Git appears to work is utterly hopeless, so I must 
have got something wrong somewhere.

> So when you send your change to the maintainers, you're sending them new
> files. There are no merge conflicts, because there is no merge.

Right. Every time you edit a file, it's actually a new file.

> So sending your changes to someone else doesn't cause merge conflicts,
> and there's no need to back them out.

OK.

> When I want to put your changes into *my* version of the files, I have
> to merge it, just like Darcs.

1. Having a copy of someone else's changes is useless unless I can 
incorporate them into the latest version of the files. This is the 
equivilent of three people taking copies of a file, editing it, and 
emailing me back three modified files. I don't want three files, I want 
*one* which has all the edits in it.

2. If I do "darcs pull", all new history is copied to my repo, and the 
working copy is updated to reflect these changes. [Assuming there are no 
conflicts of course.] That's it. That's all you have to do.

With Git, you have to do some crazy thing with comparing my working copy 
to the most recent common ancestor of my branch and the branch I'm 
pulling, creating diffs for that, comparing the most recent common 
ancestor to the snapshot I just pulled, creating a diff for that, 
combining the two diffs, and then applying that to the most recent 
common ancestor. You then have to *create a new commit object* 
representing this new combined state.

Every time you try to combine two states of the repo, it creates a new 
commit object representing the merge. Darcs, by contrast, lets me 
trivially apply any combination of changes I want. I can even create 
files with combinations of changes that have never existed before if I like.

I guess the thing that really flips my lid is that not only does Git 
require you to construct a useless merge commit every time you want to 
do something as trivial as put two changes together, but if you want to 
put new stuff into a repo, you have to somehow get the merge up to date 
first. That sounds increadibly fragile.

It also irritates me that Git insists that even unrelated changes must 
have a linear time ordering. Still, it's not like I actually have to 
*use* Git, so it doesn't really matter if I don't like it...

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

Post a reply to this message

On 4/21/2011 13:07, Orchid XP v8 wrote:
> Then yeah, you'd have to construct two versions of the repo, just like you
> would with any other version control system.

Except git. Because git doesn't store diffs, it stores files. :-)  So it's 
trivial for git to run whatever you want against two different versions of 
the files.

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

That's one of the reasons why people like centralized servers.

>>>>> 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?

No, of course not. Are you even reading what I'm writing?  Why would the 
fact that you tell git what changes you want to commit with one command then 
actually commit those with a second command mean that git can't tell what 
you changed?

> I much prefer the way Darcs does it (i.e., prompt you for which
> changes you want to include in this particular commit).

I prefer the GUI, actually. Much easier to pick out various commits to 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.

Which means you can't (for example) stop in the middle when you realize you 
forgot to make one of the 30 changes you want to commit to fix something in 
particular. You have to start over.

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

It's native to git too. You get to use the command line or a gui. You're 
really not actually reading what I'm writing, are you?

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

And if that's the case in git, then you have no trouble merging things when 
and as you want them.

>> 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

The git model seems to be something you're still fully unfamiliar with.

 > 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.

What extra work? If you just want to commit everything you've changed, you 
say "git commit -all" or some such, and away you go. If you want to take my 
changes and update your repository, you say "git pull darren", and when 
you're ready to incorporate my changes into your development, you say "git 
merge darren".  It's two steps because you don't want to tie "get Darren's 
changes" to "make sure Darren's changes are all compatible with mine."

>>> 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.

Honestly, I'm not sure I see any advantage of Darcs over git, other than 
possibly repository size. I imagine once you get enough change sets in a 
repository (think 10 years of Linux development), it could get really slow 
to check out a particular file.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/21/2011 13:28, Orchid XP v8 wrote:
> Right. Every time you edit a file, it's actually a new file.

In the repository, yes. Obviously, git knows that there's a file in your 
repository with the same path and name as a file in my repository but 
different contents.

>> When I want to put your changes into *my* version of the files, I have
>> to merge it, just like Darcs.
>
> 1. Having a copy of someone else's changes is useless unless I can
> incorporate them into the latest version of the files.

Which latest versions? Oh, right, Darcs only has one latest version, and if 
you don't want to apply changes from someone, you can't fetch them either.

> This is the
> equivilent of three people taking copies of a file, editing it, and emailing
> me back three modified files. I don't want three files, I want *one* which
> has all the edits in it.

That's the merge step. Three people send you three copies. When you're 
ready, you say "apply those changes to my copy."  I'm not sure where your 
confusion is. In Darcs, that's one step it seems - I can't get changes from 
you *without* applying them to the work I'm doing. In git, it's two steps, 
because maybe you're in the middle of something and you don't want to merge 
in my changes until the stuff you're working on actually works and passes 
tests and stuff.

> 2. If I do "darcs pull", all new history is copied to my repo, and the
> working copy is updated to reflect these changes. [Assuming there are no
> conflicts of course.] That's it. That's all you have to do.

So if you have something like Linux, where there's a new release every few 
months, you need a complete repository for every release. And if I fix a bug 
in an old release and you want to incorporate that bug fix into newer 
releases, what do you do?

> With Git, you have to do some crazy thing with comparing my working copy to
> the most recent common ancestor of my branch and the branch I'm pulling,
> creating diffs for that, comparing the most recent common ancestor to the
> snapshot I just pulled, creating a diff for that, combining the two diffs,
> and then applying that to the most recent common ancestor.

git does all that. Complaining about that is like me complaining "To check 
out a working copy from Darcs, I have to do some crazy thing about 
topological sorts on patches, then applying them to empty files in the right 
order, it's nuts!"

 > You then have to
> *create a new commit object* representing this new combined state.

Yes.

> Every time you try to combine two states of the repo, it creates a new
> commit object representing the merge. Darcs, by contrast, lets me trivially
> apply any combination of changes I want. I can even create files with
> combinations of changes that have never existed before if I like.

You can do that in git too. You have to create a commit if you want to store 
it in the repository, tho.

> I guess the thing that really flips my lid is that not only does Git require
> you to construct a useless merge commit every time you want to do something
> as trivial as put two changes together,

Commits are trivially inexpensive in git. They represent the state of some 
particular repository at some particular time. It's how you store stuff.

Say you have 25 changes in your Darcs repository, and you want a version 
that applies every change except #23. What do you put in the repository to 
represent that?

> but if you want to put new stuff
> into a repo, you have to somehow get the merge up to date first.

No. You really aren't listening to what I'm saying, so I'm not sure why I'm 
bothering.

You only have to do that step *IF* nobody is going to look for merge 
conflicts. I.e., *you* have to do that step *only* in the case that *you* 
want to change *my* repository without *me* being there. Which is something 
Darcs can't do at all.

> It also irritates me that Git insists that even unrelated changes must have
> a linear time ordering.

No they don't. Indeed, if unrelated changes had to have a linear time 
ordering, you wouldn't get merge conflicts at all, would you? Then you 
wouldn't be complaining about git having merge commits.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/21/2011 14:46, Darren New wrote:
>> So Git has a GUI tool that lets you do what Darcs does natively?
>
> It's native to git too.

Well, actually, the thing is, git has a bunch of layers. There's the layer 
to just put a file into the staging index, a command to create a commit from 
the staging index, a command to point a particular name at a particular 
commit object, etc.

Everything beyond that, including deciding what hunks get included in those 
files and so on, is at the next layer up.  In exactly the same way that 
Darcs runs on top of the file system.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/21/2011 13:28, Orchid XP v8 wrote:
> 2. If I do "darcs pull", all new history is copied to my repo, and the
> working copy is updated to reflect these changes. [Assuming there are no
> conflicts of course.] That's it. That's all you have to do.

OK, so say I have a Darcs repository and I'm working on my program. I have 
some changes in my working directory, when I come across a bug. I ask you 
about it, and you say "that's already fixed." Can I pull just that one 
change into my repository?

What if I'm working on version 1 of the program, and you made a fix in 
version 2?  How do I handle that?

Indeed, how do I get out a version of the working directory excluding just 
one particular patch back in time, in order to see (for example) if that 
patch was the cause of a bug?  I didn't see that in the Darcs manual. All I 
saw was deleting changes from the repository.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/21/2011 13:07, Orchid XP v8 wrote:
>> 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.

Actually, you can store a repository on an http server and give everyone 
read access to the repository, and everyone can update from there. So, yeah, 
it basically *can* be done by copying the right files from one place to another.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/21/2011 13:28, Orchid XP v8 wrote:
> 1. Having a copy of someone else's changes is useless unless I can
> incorporate them into the latest version of the files.

Also, does Darcs record when you applied various patches?

So if, for example, I'm working, and everything's good, and I take some 
patches from you, then work some more, then take some patches from Sam, then 
work some more, then run my test and it fails, can I figure out that it was 
Sam's patches, even if he created those patches before I even cloned the 
repository in the first place?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/21/2011 13:28, Orchid XP v8 wrote:
> Every time you try to combine two states of the repo, it creates a new
> commit object representing the merge.

Just to be clear, adding your changes to my repository is just adding a 
commit. A commit is like a Darcs patch. One update of the repository is one 
commit.

There's a "merge commit" which is nothing but a commit saying "this is what 
it looks like after you merge two commits."

That said, the Linux repository going back 234 tagged versions (back to 
2.6.11, which isn't all that far back) has 244,000 commits, of which only 
15,000 are merges. So people tend to make 10 or more changes on each branch 
before they merge it into the repository.

I'm not sure I'd want to check out something from Darcs that has a quarter 
million patches in it and wait for Darcs to apply them all one by one. How 
well does it handle that?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message