On 23/04/2011 06:46 PM, Darren New wrote:

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

Yes.

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

> 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. (Of course, what it's *actually* going to do is prompt you 
for which ones you want to record, but anyway...)

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

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

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

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

You don't do a merge every time you record a change. You do a merge 
every time somebody *else* records a change.

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

>> 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 what you're saying is, the histories in two Git repos don't actually 
have to match, only the file contents?

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

OK, "linear order within a single branch".

>> 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. Git /assumes/ that if you apply the changes in the same order that 
the author did, this is more likely to produce a working configuration, 
but there's no /guarantee/ at all.

Changes have descriptions for a reason.

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

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

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

> 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, rather 
than a set of mostly independent changes which could safely be combined 
in any combination.

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

Post a reply to this message