On 22/04/2011 11:29 PM, Darren New wrote:
> 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."

Seems more like because it's so difficult to merge two files, after 
you've done it you have to save it to prevent you having to redo all 
that complex hard work. And in the process, all change application is 
forced to become strictly linear.

Apparently this doesn't stop people working on the Linux kernel. But it 
seems really clumsy to me.

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

You're aware that Darcs keeps a cached copy of the latest state of all 
the files, so it doesn't have to recompute them, right?

Last time I tried downloading the repos for GHC, it was dominated by 
network latency. Processor usage was almost non-existent. It just takes 
a long time to shift gigabytes of data over a slow ADSL link. Just as it 
would if I had downloaded a Zip file of the source code with no history 
data at all.

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

Post a reply to this message

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

Hint: Look up "darcs fetch". It fetches changes without applying them.

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

It's the fact that you have to commit the merged version of the file as 
a new version. Every time you merge in a new change, you have to commit 
a new version. It just seems clunky and unecessary.

> In Darcs, that's one step it seems - I can't get changes
> from you *without* applying them to the work I'm doing.

Not true. You can get changes without applying them. It's just that 
usually, you want to fetch changes to, you know, *use* them.

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

Then why fetch the changes at all? Why not wait until you're actually 
ready to apply them?

> So if you have something like Linux, where there's a new release every
> few months, you need a complete repository for every release.

Um... why?

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

Oh, I see. You mean if you actually have multiple versions of something 
being developed concurrently? Yeah, in that case you'd have to move the 
changeset from one branch to another and hope it works.

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

So if two people have the same repo, and they merge in change X and then 
later merge in change Y, and then the other guy merges in change Y first 
and later change X, they now apparently have conflicting histories. (And 
all because Git wants to pretend that everything happens in linear 
order.) How do you get out of that?

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

As I say, it just annoys me that you have to assign an arbitrary 
ordering to changes.

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

You ask Darcs to revert change #23.

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

This doesn't make any sense to me at all...

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

Post a reply to this message

On 21/04/2011 06:54 PM, Darren New wrote:

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

Interesting. And here I was thinking it marks the conflicting parts of 
the files for you so you can go fix it...

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

I thought "git merge" just combines changes, not resolves conflicts.

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

I wasn't even talking about conflicts. I'm talking about the fact that 
if the central repo changes, even in a way which does *not* conflict 
with your changes, you still have to update your local repo, remerge all 
the changes, and try again.

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

I disagree, but I don't think this argument is going anywhere productive 
right now.

> The Darcs replace command is interesting, but I'm not sure how well that
> would work in practice, especially in languages with complex scoping.

Yeah, it's only really useful for global names (e.g., functions or 
types). If you've got a dozen functions with a variable named "x1" and 
you want to make it "x_in" in one of them... yeah, good luck. Really, 
you're going to have to sort it out by hand.

What should *really* happen is that Darcs looks at your edits and 
*detects* that it's a find-and-replace affecting only certain lines, and 
record that. But anyway...

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

Post a reply to this message

On 4/23/2011 3:47, Orchid XP v8 wrote:
> I will admit, a GUI is probably a superior interface for doing this. (And
> I'm not aware of anyone having built a GUI for Darcs.)

There's a couple of standard git guis that come with git. One for really 
sophisticated exploration of the history and one for manipulation of the 
repository and working directory.

>> Which means you can't (for example) stop in the middle when you realize

> True enough. It would be nice if you could make Darcs remember which changes
> you selected last time around. (Then again, some of those changes might no
> longer exist next time you run Darcs...)

Git also does some various funky things. Like if you're doing merges and you 
get a conflict, it leaves extra information in the "index" part to keep 
track of which merge conflicts you've fixed and which you haven't. The 
"bisect" routine (which Darcs has as well) uses that area to track stuff. Etc.

Of course, in git they'll still exist, because it gets copied into the 
repository when you say "remember this change", not when you say "commit".

> You still have to manually make Git combine all 200 changes into one
> version, and then commit that.

But if they don't conflict, then that's one step.  (Well, one step for each 
of the 200 changes, just like in Darcs.)

> It just seems like an undless cycle of merges
> trying to keep everything straight, generating an ever more tangled history
> behind it.

No, it doesn't really work like that. Like I said, of the Linux repo, 
there's 240,000 commits, of which 15,000 are actually merges. Git has a lot 
of ways of editing the history to make it look simpler, which is where all 
the perceived complexity of git lies.

> It's more the conceptual annoyance of having to record every merge operation
> as a new version of the entire repo, even if you only changed one line. That
> seems really clumsy to me.

Just so you know: There's merges, and there's commits. A commit is the same 
as what Darcs calls a changeset. A merge is when you have two different 
branches that you're putting into one repository.

In git, a commit is a trivial thing. You say "git commit" just like in Darcs 
you say "darcs record."  I do dozens of git commits a day just farting 
around with my own programs.

In git, a merge is when you take two branches and apply the changes from one 
branch to the other branch. In Darcs, this would involve two separate 
repositories, one being updated from the other. It's about the same 
complexity as that.

>> Honestly, I'm not sure I see any advantage of Darcs over git.
>
> Likewise, but inverted.

Well, here's the advantages of git, so far:

Git can keep multiple branches in one repository, which makes it easier to 
move changes around, look at history, try out new combinations of changes, etc.

Git keeps track of where changes came from and when, so if I pull in a 
2-month-old changeset and it breaks something, I can figure out when I 
pulled it in vs when you wrote the change. (I didn't see that in Darcs, but 
I didn't look very close.)

git keeps a history that can tell me what changes rely on other changes 
semantically, not just syntactically. (I.e., the thing Darcs tries to do 
with the retoken command, except that really only works for one specific 
type of semantic change and still only works syntactically.)

git doesn't have to spend tens of hours applying 240,000 change sets to the 
repository in order to give me the latest version of the files.

git has all kinds of sweet tools to manipulate the repository in ways Darcs 
can't very easily. (Basically, you'd have to tell Darcs to make a bunch of 
snapshots, then fiddle with the snapshots the same way git would fiddle with 
the repository itself.)

> Still, until GHC moves from Darcs to Git, I won't have to actually care, so
> I guess it doesn't really matter.

Not unless you wind up working on a project that uses git.

I think 90% of your confusion with git is you're trying to think about it 
like you think about Darcs, in terms of a series of changes, which is why I 
posted the original link 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/23/2011 3:25, Orchid XP v8 wrote:
> On 22/04/2011 12:39 AM, Darren New wrote:
>> 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.
>
> I've done this with Darcs. Unfortunately, to update the repo, you basically
> delete it off the server and copy the current version over there - which is
> tedious. (By default, the server would also have a working copy - which is
> pointless. Fortunately, if you delete that bit, it still works.)

Yeah. You can't update git via http, but you can update a repository stored 
on the server and then there's a command called "update-http-hook" or 
something that refreshes the index that clients use to quickly find files on 
the http server. (I.e., the clients need to be able to get a directory 
listing of all the heads of branches, which is something an http server 
never really standardized.)

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

Post a reply to this message

>> You still have to manually make Git combine all 200 changes into one
>> version, and then commit that.
>
> But if they don't conflict, then that's one step. (Well, one step for
> each of the 200 changes, just like in Darcs.)

Except that you have to record the order you did it in, even though it 
doesn't actually matter.

>> It just seems like an undless cycle of merges
>> trying to keep everything straight, generating an ever more tangled
>> history behind it.
>
> No, it doesn't really work like that. Like I said, of the Linux repo,
> there's 240,000 commits, of which 15,000 are actually merges. Git has a
> lot of ways of editing the history to make it look simpler, which is
> where all the perceived complexity of git lies.

I might suggest that if you *need* the ability to edit history to make 
it look simpler, you're doing it wrong.

> Just so you know: There's merges, and there's commits. A commit is the
> same as what Darcs calls a changeset. A merge is when you have two
> different branches that you're putting into one repository.
>
> In git, a commit is a trivial thing. You say "git commit" just like in
> Darcs you say "darcs record." I do dozens of git commits a day just
> farting around with my own programs.
>
> In git, a merge is when you take two branches and apply the changes from
> one branch to the other branch. In Darcs, this would involve two
> separate repositories, one being updated from the other. It's about the
> same complexity as that.

Except that with Darcs, you don't need to record the fact that a branch 
ever even existed. You just record what was done with the actual file 
contents.

> Well, here's the advantages of git, so far:
>
> Git can keep multiple branches in one repository

I don't know how that works, but if you mean you can have multiple 
working copies, then yes, I guess that could be quite useful.

> Git keeps track of where changes came from and when, so if I pull in a
> 2-month-old changeset and it breaks something, I can figure out when I
> pulled it in vs when you wrote the change.

I'm not sure I see why you would need that information, but OK, Darcs 
can't tell you about that.

> git keeps a history that can tell me what changes rely on other changes
> semantically, not just syntactically.

How?

> git doesn't have to spend tens of hours applying 240,000 change sets to
> the repository in order to give me the latest version of the files.

Neither does Darcs.

> git has all kinds of sweet tools to manipulate the repository in ways
> Darcs can't very easily.

Ways such as what?

>> Still, until GHC moves from Darcs to Git, I won't have to actually
>> care, so I guess it doesn't really matter.
>
> Not unless you wind up working on a project that uses git.

That isn't going to happen.

1. I will never wind up "working" on anything that's version-controlled. 
I am apparently doomed to spend the rest of my /working/ life rebooting 
people's PCs because Word crashed, rather than doing interesting coding 
tasks.

2. If we're talking about hobby projects, obviously I'm going to pick 
one that uses my preferred tools.

> I think 90% of your confusion with git is you're trying to think about
> it like you think about Darcs, in terms of a series of changes, which is
> why I posted the original link in the first place.

It's not that I don't understand the difference between Git and Darcs. 
It's that I can't begin to comprehend how what Git does can work. It 
just seems such an obviously stupid way to approach the problem.

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

Post a reply to this message

On 4/23/2011 4:08, Orchid XP v8 wrote:
> Not to my knowledge, no. It records who created a patch and when, but not
> when it was applied to any particular repo.

That seems a problem to me, yes. :-)

>> 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?
>
> In that case you're presumably going to revert patches until the problem
> goes away. Maybe one patch broke something, maybe its an interaction of
> several patches. You turn patches on and off until you figure out what's up.

Sure. But I can't tell after the fact when I sucked Sam's patch in, so if 
Sam wrote the patch 2 months ago and I only started seeing the problem a 
week ago, it's not obvious that it might actually be Sam's patch.

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

Post a reply to this message

On 4/23/2011 4:15, Orchid XP v8 wrote:
> Hint: Look up "darcs fetch". It fetches changes without applying them.

OK. It sounded to me like Darcs had one working copy and one repository, and 
applying all the patches from the repository would give you a "pristine" 
version, and the working version was differenced from the pristine version 
to get the next patch.

So it sounds like you can't actually fetch changes without having them 
actually be relevant to the working directory. If you make the WD match the 
repository, then fetch changes without applying them, then ask for diffs, 
isn't Darcs going to tell you the WD doesn't match the repository? If your 
change added the line ABC, isn't darcs diff going to tell you you removed 
ABC from the WD?

So what do you mean "apply"?  What happens if your WD matches the 
repository, then you do a fetch, then you say "record", what does Darcs do?

> It's the fact that you have to commit the merged version of the file as a
> new version. Every time you merge in a new change, you have to commit a new
> version. It just seems clunky and unecessary.

It's mildly clunky, but it tells you which changes are applied to which 
snapshots. git does this because it records files, not changes, yes. It's 
probably the part of git that people like least.

What happens if I have a number of tags in the repository (v1 and v2 and the 
current v3 under development), and I want to apply a bugfix to the v1 
version that doesn't apply to the later versions? How do I do that?

>> In Darcs, that's one step it seems - I can't get changes
>> from you *without* applying them to the work I'm doing.
>
> Not true. You can get changes without applying them. It's just that usually,
> you want to fetch changes to, you know, *use* them.

But if you have multiple branches, like V1, V2, and V3beta1, and someone 
sends you a new feature for V3beta1, you don't want to apply that to V1 or 
V2.  If you get a bugfix for V1 and make V1.01 you might or might not want 
to apply that to V3.

> Then why fetch the changes at all? Why not wait until you're actually ready
> to apply them?

Welcome to DVCS!

Plus, what do you mean "apply"? git stores multiple branches in one 
repository. I could as easily ask you "why wouldn't you apply every change 
you get to every copy of the Darcs repository for your program?"  The answer 
is "because maybe I don't want to change that repository."

I might want to push changes up to a shared repository so everyone in the 
team can work on them, but I don't want it going into production or even to 
people not on the team.

I might want the development branch to apply the changes but not the branch 
that's half way thru QA testing.

>> So if you have something like Linux, where there's a new release every
>> few months, you need a complete repository for every release.
>
> Um... why?

Because you don't want all the changes applied to old versions of Linux? 
Maybe Darcs tags would do the trick there?

>> 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?
>
> Oh, I see. You mean if you actually have multiple versions of something
> being developed concurrently? Yeah, in that case you'd have to move the
> changeset from one branch to another and hope it works.

And *that* is exactly what a git merge is. You don't do a merge every time 
you record a change. You only do a merge when you're actually, you know, 
merging two sets of changes into one branch of the repository.

A git branch is like a darcs repository.
A git commit is like a darcs record.
A git merge is like a darcs fetch-and-apply.

>>> You then have to
>>> *create a new commit object* representing this new combined state.
>>
>> Yes.
>
> So if two people have the same repo, and they merge in change X and then
> later merge in change Y, and then the other guy merges in change Y first and
> later change X, they now apparently have conflicting histories.

Well, you don't really "merge in" a change. You merge a change from one 
branch to another. You're not merging changes, you're merging branches.

You're not going to have conflicting histories. Indeed, you *can't* have 
conflicting histories because history is immutable. You might have different 
histories in each repository, but that's like having two Darcs repositories 
cloned from the same source but with a different set of changes in each.

So if we start at the same version, and you make three changes, and I make 
three changes, and assuming there's no conflicts, when I merge your changes 
into mine, I'll get the same files as if you merged my changes into yours, 
so we'll both wind up with the same files, except yours will say yours 
committed it and mine will say mine committed it.

Normally the only reason you'd both merge in the other person's changes is 
if you're both going to keep developing on your own. Otherwise, what you 
ought to do is I merge in your changes, and then give you the result to 
continue from.

Obviously it's not a problem if you don't later combine the repositories 
into one history. If you do, then you'll have two branches, and your pointer 
will point to yours, and mine will point to mine, and they'll each be 
pointing to a separate commit with the same files in each one (assuming 
they're identical contents and that you didn't resolve merge conflicts 
differently than I did).

 > (And all
> because Git wants to pretend that everything happens in linear order.)

No, git very specifically does *not* pretend things happen in a linear 
order.  There's all kinds of tools to examine the DAG of dependencies 
between versions.

> How do you get out of that?

If it comes time to turn your work and my work into the same branch, you 
just merge the two branches in both repositories and work from there on, 
which won't cause any merge conflicts because they're all the same files. 
It's a DAG.

It would be similar in Darcs as if I set a tag in my repo and you set one in 
your repo, then we merged them, and now you ask "how do you make a tag that 
incorporates all the changes?"  Well, if I took your changeset and you took 
my change set, we'd have two tags. Make a third tag that points to the 
combined set.

> As I say, it just annoys me that you have to assign an arbitrary ordering to
> changes.

It's not really arbitrary. Darcs just ignores the fact that they aren't.

If I add function AAA to file BBB and record that change, then add a call to 
function AAA into file CCC, then record that change, would that really be 
independent unordered changes in Darcs?  That seems awfully fragile.

>> 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?
>
> You ask Darcs to revert change #23.

And how do you do that? "darcs revert" doesn't do that. "darcs unrecord" 
throws the change away entirely. Obliterate deletes the patch entirely as well.

So it sounds like the actual answer is "you have to clone the entire 
repository, then you have to obliterate the patch, and then you have to 
rebuild the working directory from the new repository, and *then* you're 
done, yes?

>>> 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?
>
> This doesn't make any sense to me at all...

Patches within any one branch have a linear time ordering. But git handles 
multiple branches in the same repository. So changes between branches aren't 
linearly ordered.

If changes were all linearly ordered, you'd never have to resolve merges, 
because you could never have two independent patches trying to be applied to 
the same place in the file, because one would definitely come before the 
other, right?

Even on the same branch, while the changes are recorded linearly, if there 
aren't conflicts between them, it's trivial to rearrange the order however 
you want. Just like in Darcs you can't rearrange a patch that deletes a line 
to be applied earlier than the patch that creates the line, so there's a 
partial ordering in Darcs also. Same in git - it's a DAG with a partial 
ordering. It's not linear.

For example, attached is a picture of the last few dozen commits to the 
Linux kernel.

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

Post a reply to this message

Attachments:
Download 'image1.png' (172 KB)

Preview of image 'image1.png'

On 4/23/2011 4:14, Orchid XP v8 wrote:
> Seems more like because it's so difficult to merge two files,

It's no more difficult in git than in darcs. It's exactly the same process. 
You apply one set of diffs, then the other. If there are no conflicts, 
you're done. If there are conflicts, you fix them, and you're done.

If there's a branch called "newstuff" and I'm working on "master", and I 
want to merge in the changes from newstuff, I say

git merge newstuff
git commit

If file ABC has a conflict in it, I say

git merge newstuff
vi ABC
git add ABC
git commit

> after you've
> done it you have to save it to prevent you having to redo all that complex
> hard work.

Yes.  Except it's exactly as hard and complex as in Darcs.

> And in the process, all change application is forced to become
> strictly linear.

git doesn't record changes, so no, change application isn't forced to become 
linear.

> Apparently this doesn't stop people working on the Linux kernel. But it
> seems really clumsy to me.

It seems clumsy because you keep thinking git is recording changes. You keep 
thinking of "changes" instead of "versions".

>> 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?
>
> You're aware that Darcs keeps a cached copy of the latest state of all the
> files, so it doesn't have to recompute them, right?

Sure.

> Last time I tried downloading the repos for GHC, it was dominated by network
> latency. Processor usage was almost non-existent. It just takes a long time
> to shift gigabytes of data over a slow ADSL link. Just as it would if I had
> downloaded a Zip file of the source code with no history data at all.

Yep. But you only got the latest version. If you wanted to get every tag, 
you wind up copying all those files again anyway.

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

Post a reply to this message

>> In that case you're presumably going to revert patches until the problem
>> goes away. Maybe one patch broke something, maybe its an interaction of
>> several patches. You turn patches on and off until you figure out
>> what's up.
>
> Sure. But I can't tell after the fact when I sucked Sam's patch in, so
> if Sam wrote the patch 2 months ago and I only started seeing the
> problem a week ago, it's not obvious that it might actually be Sam's patch.

Or, to summarise, "if I let my repo get 6 months out of date with the 
upstream and then pull everything in at once and try to figure out why 
it broke, it'll be quite difficult". My general reaction being "don't do 
that", but OK, I guess it's a valid complaint...

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

Post a reply to this message