[Top][All Lists]

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

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

From: Greek0
Subject: [Gnu-arch-users] Re: [MERGE REQUEST] changeset translation preparatory work
Date: Sun, 30 May 2004 13:01:56 +0200

On Sun, 30 May 2004 16:34:44 +1000
Jamie Wilkinson <address@hidden> wrote:

> This one time, at band camp, Miles Bader wrote:
> >On Sat, May 29, 2004 at 10:12:48PM -0400, Colin Walters wrote:
> >> I'm not really suggesting it be customizable.  Instead I'm
> >proposing to> default to the way the obviously vast majority of other
> >software out> there names files.  Even inside arch I think it's
> >pretty clear (from> .arch-inventory and .arch-ids) that the { and =
> >are basically just> legacy.
> >
> >No, it's not clear at all.  .arch-inventory and .arch-ids are not the
> >same as{arch}.
> >
> >Let me put it this way: If I was allowed to choose, with all
> >compatibility problems magically solved, I'd choose {arch} over .arch
> >(I'd do some things differently, I think, but not that).  I think
> >that subversion made a mistake when they chose .svn.
> Colin, I think this is a great idea.
> I personally much prefer the hidden directory over the plainly
> visible, and given that this will only affect local working copies I
> hardly think it's worth getting worked up about; I assume that within
> changesets themselves the classic names will remain.
> It also sounds like ".arch vs {arch}" is a moot point anyway, with
> Colins patches the end user has the option of naming that directory
> however they like, and it will not affect anyone else.

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. What's even worse
is that there will be 2 possibilities. {arch} vs .arch. Perhaps even
more, I don't know how Colin want's to implement it. In the first case
you have to check if any of these 2 dirs exist, in the second case you
need a special tla command to get the path to the meta-data, or you
store the arch-meta-data-directory-name in some file in ~/.arch-params.

How should it be customizeable? Should the dir name be compiled into
tla? Should it be per-machine? Per-user? Per-archive? Compiled in seems
to suck. With per-machine and per-archive the question comes up: where
do you store the dir-name? 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.

Personally I'm not too annoyed with {arch}, but I think .arch would be
nicer anyway, if it would have been done that way right from the start.
There are just a lot of problems doing it now. Moreover, for beginners
to really use it, it'd have to be the default.
I don't think there's any chance that Tom ever merges this.

IMHO there are quite a few annoyances with arch, the archive format, ...
I think it would be nice to do break compatibility some time, if it's
possible all at once. Eg. with tla v2. Make the archive format more
portable (ie. eleminate long pathnames), change {arch} to .arch or
something like that, and some other things that don't come to my mind
now. IMHO it would be great to do something like this soon, parallel
with implementing the feature plan. I don't know what Tom thinks of it


reply via email to

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