On Fri, 2005-04-08 at 19:05 -0500, John Arbash Meinel wrote:
> 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 c
On Fri, 2005-04-08 at 15:22 -0700, Tom Lord wrote:
>>> Always giving root the same tag means that many important control
>>> files always have the same tag (using only generic rules for how those
>>> tags are constructed).
>
> > Uhm. All current files in Arch are either names tagged
From: John Arbash Meinel <[EMAIL PROTECTED]>
Why doesn't arch assign the id based on the patch log fully qualified
revision?
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 fu
Tom Lord wrote:
From: John Arbash Meinel <[EMAIL PROTECTED]>
Why doesn't arch assign the id based on the patch log fully qualified
revision?
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.
On Fri, 2005-04-08 at 18:51 -0500, John Arbash Meinel wrote:
> Tom Lord wrote:
>
> > From: John Arbash Meinel <[EMAIL PROTECTED]>
> >
> > Why doesn't arch assign the id based on the patch log fully qualified
> > revision?
> >
> >It *does*. It does that too. The same id makes sense when vi
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 cor
Robert Collins wrote:
On Fri, 2005-04-08 at 18:51 -0500, John Arbash Meinel wrote:
Tom Lord wrote:
From: John Arbash Meinel <[EMAIL PROTECTED]>
Why doesn't arch assign the id based on the patch log fully qualified
revision?
It *does*. It does that too. The same id makes sense when viewed th
Tom Lord wrote:
>> Always giving root the same tag means that many important control
>> files always have the same tag (using only generic rules for how those
>> tags are constructed).
> Uhm. All current files in Arch are either names tagged
> - ?[_]./path/to/file-or-dir
> or explictly id'
>> Always giving root the same tag means that many important control
>> files always have the same tag (using only generic rules for how those
>> tags are constructed).
> Uhm. All current files in Arch are either names tagged
> - ?[_]./path/to/file-or-dir
> or explictly id'd via ex
On Wed, 2005-04-06 at 14:32 -0700, Tom Lord wrote:
> Always giving root the same tag means that many important control
> files always have the same tag (using only generic rules for how those
> tags are constructed).
Uhm. All current files in Arch are either names tagged
- ?[_]./path/to/file-or-di
David Allouche wrote:
On Tue, 2005-04-05 at 07:47 -0400, Aaron Bentley wrote:
David Allouche wrote:
In an aggregation tree, when merging a file addition at the root of a
component tree, should the file be added at the root of the aggregation
tree or the root of the aggregated tree?
You say it shoul
On Tue, 2005-04-05 at 07:47 -0400, Aaron Bentley wrote:
> David Allouche wrote:
> >
> > Anyway, when you have different imports of the same code base, you are
> > in trouble, since all the file ids are different.
>
> I'm talking about the case where you have two or more trees, and you
> decide t
David Allouche wrote:
On Mon, 2005-04-04 at 00:46 -0400, Aaron Bentley wrote:
Robert Collins wrote:
We should probably make init-tree perform 'add .' on the fly.
It's hard to say. When you have two trees with different origins but
the same files, it's irritating if root isn't root. ID aliases wo
On Mon, 2005-04-04 at 00:46 -0400, Aaron Bentley wrote:
> Robert Collins wrote:
> >
> > We should probably make init-tree perform 'add .' on the fly.
>
> It's hard to say. When you have two trees with different origins but
> the same files, it's irritating if root isn't root. ID aliases would
On Sun, 2005-04-03 at 13:04 -0400, Aaron Bentley wrote:
> David Allouche wrote:
>
> > And I remembered the previous discussions on associating an inventory ID
> > to the tree-root. The tree-root used to be a bit special, but it's
> > actually a problem to the changeset logic.
>
> In fact, the tre
Robert Collins wrote:
On Sun, 2005-04-03 at 13:04 -0400, Aaron Bentley wrote:
Thats the hard coded fall-back default. tree roots can have ids -
trivially try:
Cool.
init-tree
add .
id .
We should probably make init-tree perform 'add .' on the fly.
It's hard to say. When you have two trees with d
David Allouche wrote:
And I remembered the previous discussions on associating an inventory ID
to the tree-root. The tree-root used to be a bit special, but it's
actually a problem to the changeset logic.
In fact, the tree-root does have an id in the changeset logic. It's
always "?_.", but never
On Sun, 2005-04-03 at 19:12 +1000, Robert Collins wrote:
> On Wed, 2005-03-30 at 11:46 -0600, John Arbash Meinel wrote:
> >
> > Is it a bug that inventory -t doesn't catch "."? Or is this a design
> > decision?
>
> Its not an explicit decision, and I think its reasonable to consider it
> a bug.
On Wed, 2005-03-30 at 11:46 -0600, John Arbash Meinel wrote:
> John A Meinel wrote:
> One problem with inventory --nested -t, it doesn't detect "."
> I'm not sure if there is a reason for this, but if I am crawling the
> directory to find source directories (so that I can run changes/status
> in t
John A Meinel wrote:
Robert Collins wrote:
...
bazaar$ baz inventory --nested -t
debian
src
src/baz
src/baz-manpage
src/hackerlab
Cheers,
Rob
Thanks, I guess I never saw the '-t' flag. It's a little bit of a pain
on really large trees, because tla crawls the whole tree before I can
start working o
Robert Collins wrote:
On Tue, 2005-03-29 at 18:07 -0600, John A Meinel wrote:
Robert Collins wrote:
...
What are you supposed to do when you want to *crawl* a heavily nested
set of trees? Crawl and spawn tree-root for each one?
I know there is inventory --nested, but what I want is tree-root --nest
On Tue, 2005-03-29 at 18:07 -0600, John A Meinel wrote:
> Robert Collins wrote:
> > On Tue, 2005-03-29 at 17:18 -0600, John A Meinel wrote:
> >
> >
> >
> >>As far as $wd/{arch}, I like that it is unique, it makes writing scripts
> >>that do stuff in each root directory fairly easy to write. But pro
Robert Collins wrote:
On Tue, 2005-03-29 at 17:18 -0600, John A Meinel wrote:
As far as $wd/{arch}, I like that it is unique, it makes writing scripts
that do stuff in each root directory fairly easy to write. But probably
.arch is also unique (and matches well with .arch-ids, .arch-inventory,
etc
On Tue, 2005-03-29 at 17:18 -0600, John A Meinel wrote:
> As far as $wd/{arch}, I like that it is unique, it makes writing scripts
> that do stuff in each root directory fairly easy to write. But probably
> .arch is also unique (and matches well with .arch-ids, .arch-inventory,
> etc). I certainl
24 matches
Mail list logo
