[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG] feature plan -- version variables
From: |
Aaron Bentley |
Subject: |
Re: [Gnu-arch-users] [BUG] feature plan -- version variables |
Date: |
Tue, 25 May 2004 15:23:49 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040309) |
Tom Lord wrote:
> Why iso-8859-1? Since we plan to make patchlogs utf-8,
(We do? That may be where we left off the discussion but I don't think
any final decision has been made. That proposed decision strikes me
as a poor one, at the moment.)
Yes, that was what I recall. We discussed adding an encoding header and
barfing at commit time if that encoding wasn't utf-8.
At the time, you seemed to feel it was a good idea to allow utf-8 for
log contents, but I don't recall whether it was to be applied to headers.
> I'd imagine limiting it to ASCII until we make patchlogs utf-8.
You're confused.
You're talking about how a version variable value is written.
I'm talking about what the version variable value may contain.
Well, maybe I was a little confused, but I prefer making the
representation and contents the same, where possible, and if delaying
utf-8 until it's available in the representation is necessary to do
that, it suits me fine.
(The reason for this restriction is not to control the contents
of patch-logs but to simplify the C interface for manipulating these
lisp-like values. I don't want to drag in a dependency on a Unicode
based interface just yet.)
If you make it iso-8859-1 now, you can't make it utf-8 later. Restrict
it to ASCII, and you don't have to decide now.
> Are those map semantics? I'd imagine if the same name appears multiple
> times, only the last assignment is used? Or is it an error?
Interesting question.
I think the way to do it is:
1) `commit' and friends won't commit a changelog that sets the same
name twice.
2) When _reading_ a variable value, ./{arch}/++variables takes
precedence but if the variable isn't set there, and is set
twice in the most recent log entry, then that variable can't
be read.
> Care to specify a representation for lists, or do you think the list
> user should chooose it?
I have no idea what you mean. Lists are written with parentheses.
Never mind, you clearly have (3 4 1) in mind as list format.
>> If the file ./{arch}/++variables exists then it should contain
>> 0 or more valid `set-in-version' log message headers -- these
>> override the settings in the latest patch log entry.
> Is this file immortal, or is it deleted by commit/import?
Probably deleted by commit/import but only after being copied into the
log message.
(You meant "after the commit/import succeeds", right?)
A related question is whether or not (or which) variable values should
be copied from one branch to another by `tag'.
There are definitely some that should not be copied by 'tag', like
branch-description or branch-class. None that should be copied come to
mind immediately.
> Would this delete a version-var?
> % tla version-var name #f
> (Is there any difference between a false value and a missing value?)
If a variable is _not_ set locally, then its value is determined by
the most recent patch log entry.
Right, but is there a way of deleting version vars so that they no
longer appear in the patch-log, or are you stuck with foo appearing in
every patch-log even if it's set to #f?
Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.
Re: [Gnu-arch-users] [BUG] feature plan -- version variables, Bug Goo, 2004/05/28