Re: [Gnu-arch-users] [BUG] feature plan -- version variables

[Aaron Bentley]

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.