[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 Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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