[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-arch-dev] Re: [Gnu-arch-users] new documentation progress

From: John Arbash Meinel
Subject: Re: [GNU-arch-dev] Re: [Gnu-arch-users] new documentation progress
Date: Fri, 08 Apr 2005 19:05:34 -0500
User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)

Robert Collins wrote:

On Fri, 2005-04-08 at 18:51 -0500, John Arbash Meinel wrote:

Tom Lord wrote:

 From: John Arbash Meinel <address@hidden>

 Why doesn't arch assign the id based on the patch log fully qualified

It *does*.  It does that too.   The same id makes sense when viewed that
way or when viewed as simple algebra on relative path names.

That's the point.  Why fuss with it?


The id is currently:

I'm wondering why it isn't just

The issue is that as long as you keep the directory structure the same,
there is no difference. But if you want to move where files are stored
(as in what I'm trying to do), you have to leave the arch-id as the
original path-based name.

I'm doing that, but it doesn't *feel* like the correct thing. The id
shouldn't be caught up in a specific implementation of the arch protocol.

Ack. However until we spec up and get some consensus on the behaviour of
id aliases, we need to preserve the id for changesets that pun patch-log
presence with file paths, and synthesis it from disk formats.


I'm definitely going to play the part of compatibility over supposed
correctness. I plan on making changesets fully compatible with as many
other people as possible.
However, if there is ever a version 2.0 which breaks compatibility, this
might be another thing to think about.

I think I understand what Tom is saying about the baz archive
potentially hiding useful information. Though I don't know when it is
useful to have an empty branch, I can see that you might be making a
statement. (Certainly you could set the permissions on an empty branch,
such that someone else couldn't
create it, in the case that you want to reserve --rel-- and have it be

I also can't say that I've thought about any of this nearly as much as
Tom has. But I don't think he has fully conveyed all of his ideas, such
that the rest of us are convinced.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]