On 4/23/2011 11:55, Orchid XP v8 wrote:
>> If your change added the line ABC, isn't darcs diff going to
>> tell you you removed ABC from the WD?
>
> I'm not precisely sure what you're asking.

If I bring my WD up to date, then I fetch changes, then say "record", isn't 
that going to record a diff that backs out all your changes?

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

>>> 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.
>
> It's the part I least like, at any rate.

The tool that shows history has options to leave out commits that are 
nothing but merges without any other changes. :-)

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

>> I might want the development branch to apply the changes but not the
>> branch that's half way thru QA testing.
>
> The Darcs way to do this is to store copies that are meant to be different
> in different places - which seems fairly logical to me. (Admittedly a little
> inefficient on disk space...)

And a bit fragile. The idea of git is that you have a repo with all the 
history in it. You don't have to chop it into multiple repos in order to 
actually exclude some of the history from here and there.

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

>> 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.
>
> Except that you don't explicitly keep a record of a darcs fetch-and-apply.

Exactly. Which seems like a downside to me more than an upside. It means you 
have to have separate repos for different versions of the same program, 
duplicating all that history and making it "fragile" in the operational 
sense (as in, too easy to accidentally update a repo with changes that 
shouldn't be there, with no easy way to remove those changes since the fact 
that you fetched them isn't recorded).

> 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. 
Indeed, since each file is stored with a name based on the hash of its 
contents, it's literally impossible to have the same content in two 
different files.

> OK, "linear order within a single branch".

Yes. And that's a *good* thing, I'd posit, for the reasons I mentioned in 
other threads.

>>> 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.
>
> Darcs doesn't guarantee that a particular combination of patches will
> produce a working combination of files. Neither does Git, or RCS, or CVS.

Yes. But more than that, Darcs doesn't record what your WD looked like at 
the time you created the changes. *That* is the problem.

In Darcs, I'd have much more trouble tracking this bug down. In git, I'd be 
able to see that you created your patch before you knew about my change to 
function AAA, and maybe that's the source of the problem. In Darcs, I don't 
think I have any way of looking at your patch to CCC and saying "what 
version of file BBB was he reading while he was writing file CCC?"

> Changes have descriptions for a reason.

A manually-entered description isn't going to say what versions of the files 
you *didn't* change you were relying on. That's where the commit history in 
git helps out.

>>>> 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.
>
> "darcs rollback" does it though.

Oh, OK. But again it makes a permanent change in the repository. I guess 
you'd have to clone the entire repository, then roll back that one patch.

> OK, fair enough. But changes within a branch are linearly ordered.

Yes, and that's a good thing. You can trivially reorder them if they're 
independent, but there's no way of knowing whether they're really 
independent.  Git assumes they aren't, and if they are, you can reorder them 
if you care. Darcs assumes they are unless you tell it so.

>> For example, attached is a picture of the last few dozen commits to the
>> Linux kernel.
>
> What we see here is a long tangled history of sequential changes,

I'm not sure how you get a tangle of sequential changes. What does that even 
mean?

> than a set of mostly independent changes which could safely be combined in
> any combination.

Each of those strings of sequential history is a set of independent changes.

I don't think Darcs is any less tangled, or to the extent it is, I'm not 
sure it would be accurate to rearrange them.

Might I ask, why do you care? You're talking about a VCS being a record of 
the history of changes, and your biggest complaint against git seems to be 
that it's actually recording the history of changes. Darcs seems to throw 
away useful information about the history of the changes in the hope that it 
can automatically deduce enough of the history not to break in the future.

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

Post a reply to this message