Re: [Gnu-arch-users] Re: [MERGE REQUEST] changeset translation preparatory work

[David Allouche]

On Sun, May 30, 2004 at 10:45:49AM -0400, Colin Walters wrote:
> On Sun, 2004-05-30 at 07:01, address@hidden wrote:
> 
> > You miss one major point. It's been mentioned by Miles already. What
> > about compatibility with other apps and wrappers around tla? Some
> > functions will break if {arch} doesn't exist any more.
> 
> My growing feeling about this is that if any apps or wrappers do, they
> are buggy.  You want to find the tree root?  Use "tla tree-root".  Want
> to find out the tagging method?  "tla tagging-method".  See all the
> patch logs? "tla logs --merges".

My personal empirical experience is that things are _not_ that simple.

What tree-root _seems_ to do is only search upwards for a {arch}
directory. So far, so good. What about wanting to same some expensive
fork/execs by reimplementing this little feature in the wrapper? Yeah,
one rather sholud use libtla, but currently, libtla is vapor.

What if I want not just to know the tagging method, but also the naming
convention regexen? And untagged-source behaviour? What if I want to
modify them from within my wrapper? To do that, I need to be able to
poke {arch}/=tagging-method from within the script/wrapper, so there
must be a way to locate it.

What if I want to use the {arch} directory to store some additional
metadata? Right now I'm thinking of ++merge-sources used by aba. I think
it just makes sense to store them along with "{arch}/++default-version".
(Not sure 100% that is currently allowed by tla, if that's not, my
position is that should probably be considered a bug in tla).

About accessing the patchlogs, I tend to agree with you that this should
only be done through tla/libtla. But it might only be because no one so
far has had a use for a demanding application which requires saving the
pesky fork/exec overhead.

> 
> > How should it be customizeable? Should the dir name be compiled into
> > tla? 
> 
> I think it will be say ~/.arch-params/default-project-tree-version.

I think someone is going to call a category
"default-project-tree-version" just to annoy you :-> 

> 
> > With per-user you get the problem that user A
> > migth not be able to do anything on a wd of user B, if their dir-names
> > differ. He can't even do a simple tla changes or anything like that. It
> > might still be the best option though.
> 
> Yes.  But I think the case of two users who are using different versions
> of tla but sharing a working directory would be quite uncommon, if it
> would ever really happen.

If you do it, please make it a per-user customization, and please
provide programmatic solutions to know the names of whatever you can
think of renaming.

I would really hate to have to support name-guessing heuristics!

-- 
                                                            -- ddaa