On 4/23/2011 12:38, Orchid XP v8 wrote:
>>>> 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?
>>>
>>> Records a new patch reverting all the changes that you didn't apply,
>>> presumably.
>>
>> That sounds really dangerous to me.
>
> Even though it explicitly prompts you whether you want to record each of
> those changes?

Yes.

>>> You can't really use tags for that; you'd have to have seperate repos for
>>> v1, v2 and v3. Oh, you *can* put all the patches in one repo, but it's
>>> going to get messy very quickly.
>>
>> See, git has no trouble with that. One repo has all of every version of
>> Linux since 2.6.16 or so.
>
> But is that better?

I'd say so. YMMV.

> If Darcs does have a weakness, it's that it mostly assumes that the main
> thing you want to do is perform modifications to the one single "latest
> version" of stuff. It could be made more flexible in this direction, yes.

Yeah, that's it. And that everyone is pretty much working on the same 
version of stuff. Works for small scale, not so much for large scale, I think.

>>> You don't do a merge every time you record a change. You do a merge every
>>> time somebody *else* records a change.
>>
>> No, you do a merge every time you want to *apply* someone else's changes
>> to your working directory.
>
> Well, yes, that's what I meant.

Well, that's a different thing. I can record a dozen changes which you apply 
only once.  In the linux kernel it seems to be about 15:1 ratio.

>>> So what you're saying is, the histories in two Git repos don't
>>> actually have to match, only the file contents?
>>
>> The histories merge if two histories bring you to the same set of
>> contents.
>
> I see. I was assuming that if two repos disagree about history, your
> computer would explode or something. So Git is actually smart enough to
> handle that?

There's only one history. Nothing you put into a repo ever changes or 
disappears. So both histories are in the repo, and at the point where I drew 
yours in, it got linked into my history as a loop earlier in the development.

> I'm guessing this curious glitch is related to the designer's "one true
> latest version" mentallity. The whole *point* of storing history as a set of
> changes should be to make this kind of task easy.

Yeah, I think that's the basic problem I have with Darcs. All the things 
that make git complicated compared to darcs have to do with having one 
repository having lots of different versions being developed at different 
speeds.

> This, fundamentally, seems to be what it all comes down to. You seem to
> think that this information is *useful*, whereas to me it's annoying clutter
> that I'd rather not have to waste time explicitly micro-managing.

You really don't have to micromanage it. The git commands are all pretty 
much isomorphic to the darcs commands. It's extremely useful when you merge 
in a change and something breaks, so you can easily go "Oh, I see why, 
because his change says "outputs index counter" and I changed the output 
function *since* he started work on that."

Without that clue, you have to actually look at the "outputs index counter" 
change and read it to see what version of the output routines he's 
expecting, which can be especially confusing if he *wrote* the patch after 
you changed the output function but before he merged and applied your patch.

I'm not all that sure how you can't see how that's helpful. :-)

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

Post a reply to this message