* for 1.0.x


* for 1.1.x

** tla add-tag argument checking

  Don't add tags for files that don't classify-by-name as source.
  (reminder from Mark Ferrell)

** users are being confused by commit --files syntax -- add a second
   command?

** plenty 'o votes for generalizations of commit --files both to
   other commands (e.g,. undo) and broader classes of applicability
   (e.g., file adds/removes/renames)

** support for (external tool) 3way merging (Jan Hudec -- also has
   some tools that layer on existing commands for this.)

** auto-tuned archive-caching and build-revision

   Extend archives so that the sizes of archive-cached revisions
   and changesets are recorded in revision directories.

   In build-revision, distinguish local from remote archives (by
   URI by default, with option to override) and, for remote archives,
   use those numbers to decide when it is better to use the closest
   archive-cached revision vs when it is better to build-by-patching
   from some more distant local resource.

   Add a command to auto-update what is archive-cached, basing the 
   decision on those numbers.  (From discussions with Evan Prodromou.)


** support for an arch-specific path for tar, etc.

** multi-line "usage:" output from opts.c

   The tla version uses hackerlab's opt.c module, which constrains
   the output of -h (--help) to have just one "usage line", as in:

      % tla update -h
      update a project tree to reflect recent archived changes
      usage: tla update [options] dir [newdir] [version/revision]
      [...]

   It's worth comparing that to larch:

      % larch update -h
      merge local changes with the latest revision
      usage: update [options] old-dir new-dir [[archive/]version]
      usage: update [options] --in-place dir [[archive/]version]
      [...]

   which is obviously much clearer.


** fully generalized naming conventions (assufield) (see below)

   An arch-users message, summarized below, explains the plan.


** tagging-method generalization (see below)

   An arch-users message, summarized below, explains the plan.


** hooks suitable for making --no-pristine a default (with rev lib)
   and for on-demand lib filling (Damien Elmes)

   There are a couple of functions in libarch that are called when
   some command goes hunting for either a pristine copy or an archive
   cached copy of some revision.   (One of these will even build a
   scratch copy if no pristine or rev lib entry is found.)

   So, let's put some hooks in there.   A user's hook can say, "oh,
   you wish that was in the revision library?  Here, lemme add it."

   By calling a hook even when a revision is found already cached,
   the hook implementation can keep track of which revisions are
   in "greatest demand".

   (These open a _huge_ window for self-tuning, fully automatic, local
   caching by a _wide_ variety of strategies.)


** hooks for auto-push-mirroring

   Similar to the above, except hooks for reading from archive mirror.
   Should the mirror be updated from its source automatically?  On a 
   commit, should a mirror be updated from the newly modified archive?


** arbitrary-string-tags

   We aren't going to quickly convince people to change their
   practices for naming releases and so forth to conform to the
   arch global namespace.   So, let's add "free form tags" to arch.  

   The (versioned) definition of a free form tag can be recorded in 
   the log messages of versions named:

	Tags--mangle($tag)--0.1

   where `mangle' is an invertable transformation of a free-form tag
   into a valid branch name.

   Commands that accept revision names can be extended to accept the
   syntaxes:

	%$tag    $archive/%$tag


** commit --files should permit file adds (Christian Thter)

   Some confusion on arch-users initially led me to think that 
   adding new files with `commit --files' couldn't be supported but,
   for the life of me, I can't figure out why I believed that.
   (So, it should be supported.)


** star-merge : merge of mutually merged branches

   People (besides _me_) don't yet miss star-merge in tla.
   But they will, brother, they will.


** more tutorial improvements

   The tutorial has fallen behind a bit.    Jame Gosling recently
   said something like, "It's amazingly nice being able to work with
   good tech writers from the earliest stages of a project."   

   Lucky bastard.

   (Overall, empirically, the current tutorial is _way_ more effective
   than the original larch manual -- but I think it still only barely
   scratches the surface of what could be achieved.)


** add a library of useful hook functions

   See, for example, the hooks proposed above.


** file permissions bugs (umask, conflict handling) (goes with
   timestamp optimization)

   Actually, this item is slightly out of date.

   The "changing permissions seemingly randomly" bugs are squashed,
   I think.

   The remaining issue concernes umask.   When building revisions from
   archives, tla currently overrides umask -- is it worth having an 
   option to not do so?   If so, what does that imply?


** add the timestamp optimization for `commit'

   With various record keeping, we can avoid having to diff every file
   during the common cases of whole-tree commits.


** add the `unwanted' mechanism

   Patch logs should include `unwanted' patches -- patches not applied
   but that should not appear in `whats-missing' output (for example) 

   My current thinking is that, within a patch-log directory, while a
   file like "patch-5" means "the changeset for patch-5 has been
   applied somewhere in the history of this tree", a file like,
   "u.patch-5" means "somewhere in the history of this tree, someone
   decided that patch-5 was undesirable."


** write the "backing out changes" section of tutorial
   (do `unwanted' support first)

  Unwanted will make the techniques for backing-out changes fancier.


** magic caches and magic mirrors (requires hooks first)

  Using hooks, manage mirrors and revision libs automagically.


** --skip-present option to replay?  or whats-missing?

** cvs annotate-style functionality

** have tree-lint bitch about missing regexps in 
   =tagging-method

** forbid ctl files from being symlinks

** forbid config subtree roots from being reached via symlinks

** forbid snap-config etc. from writing through symlinks

** validate *-index file contents in patches

** watch out for bogus symlinks in changesets

** rel_join_output, rel_cut_list -- make them not leak memory

** arch_archive_revisions full parameters should be an enum -- similar
   for other revision list functions.

** some cmd_* functions leak memory (having 
   formerly been main() functions)

** add a command to delete empty categories/branches/versions?

** add support for a top level archive index file (analogous to
   .listing) to speed up mirroring

** % tla make-archive --mirror-from remote-location directory
    and have both the archive names registered and set up ready for local
    mirroring. You have to rely on =meta-info/name giving the correct name
    of the archive though.  (stig)

** % tla register-archive existing-archive-location

    should not require an archive name. It should register the archive
    based on =meta-info/name and spew out a message saying what the
    name of the archive is. (stig)



From: Tom Lord <lord@emf.net>
To: arch-users@lists.fifthvision.net
In-reply-to: <20030623230843.GA9298@iup.edu> (message from Jason McCarty on
	Mon, 23 Jun 2003 19:08:43 -0400)
Subject: tagging method design space (was Re: [arch-users] explicit tagging and tree-lint)
Sender: arch-users-admin@lists.fifthvision.net
X-BeenThere: arch-users@lists.fifthvision.net
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: arch-users@lists.fifthvision.net
List-Help: <mailto:arch-users-request@lists.fifthvision.net?subject=help>
List-Post: <mailto:arch-users@lists.fifthvision.net>
List-Subscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=subscribe>
List-Id: Arch users discussion list. <arch-users.lists.fifthvision.net>
List-Unsubscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=unsubscribe>
List-Archive: <http://lists.fifthvision.net/pipermail/arch-users/>
Date: Mon, 23 Jun 2003 17:16:27 -0700 (PDT)
X-Spam-Status: No, hits=-1.3 required=5.0
	tests=AWL,IN_REP_TO,KNOWN_MAILING_LIST,MSG_ID_ADDED_BY_MTA_3,
	      REFERENCES
	version=2.54
X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
X-UIDL: 8a00861cb89f1a0a86355db35a1579f6



Sigh.

Tagging methods can be simplified by introducing some new
=tagging-method directives:


	embedded-tag   REGEXP

means to search files for implicit or tagline-style tags, based on
REGEXP.

	external-tag

means to look for .arch-ids/ directories and get tags from those.

	untagged-source		{source,precious,unrecognized}

determines what happens to source files that pass naming conventions
as source, but for which no tag can be computed.

=tagging-method files that use those directives would not need to use
any of the keywords names, implicit, tagline, or explicit (or
explicit-tagged).

The existing tagging methods come out as short-hand for certain
settings of those three:


	names ==
		untagged-source		source

	implicit == 
		external-tag
                embedded-tag		^[[:punc:]]*tag:[[:blank:]]*
                untagged-source		source

	tagline == 
		external-tag
                embedded-tag		^[[:punc:]]*arch-tag:[[:blank:]]*
                untagged-source		source

	explicit == 
		external-tag
                untagged-source		unrecognized

The proposed:

	explicit-tagged == 
		external-tag
                untagged-source		precious



Because embedded-tag accepts a regexp (and might even reasonably
accept some more complex rule, like a mapping from filename extensions
to regexps), the space of tagging methods is infinte.

But if we regard embedded-tag as just a binary choice (are embedded
tags used at all, or not), then the space is still largish:


	external-tag = 1/0
        embedded-tag = 1/0
        untagged-source = source/unrecognized/precious


2*2*3 = 12.

Of course, these two settings make no sense:

	external-tag = 0
        embedded-tag = 0
        untagged-source = unrecognized

	external-tag = 0
        embedded-tag = 0
        untagged-source = precious

which leave 10.

I think these settings make little-to-no sense:

	external-tag = 0
        embedded-tag = 1
        untagged-source = <any>


which leaves seven.

All the others make sense.  By this method of counting (in which
`implicit' and `tagline' count as just one tagging method, differing
only by the embedded-tag regexp) We currently have three, and
explicit-tagged would make 4.

The three sensible but unsupported names (after explicit-tagged) would
be:

	external-tag = 1
        embedded-tag = 0
        untagged-source = source


	external-tag = 1
        embedded-tag = 1
        untagged-source = precious			


	external-tag = 1
        embedded-tag = 1
        untagged-source = unrecognized


The upshot of this is that there is a design choice:

(a) give names to those three "missing" methods, parameterize
    `implicit', `tagline', and two of the new methods with a 
    regexp for the tag-line ("implicit" and "tagline" would imply
    different defaults for that regexp).

(b) add the three directives, give warnings or errors for nonsense
    combinations, and use the existing tagging method names as
    short-hand for certain settings.

(I'm inclined towards (b).)


-t
_______________________________________________
arch-users mailing list
arch-users@lists.fifthvision.net
http://lists.fifthvision.net/mailman/listinfo/arch-users



From: Tom Lord <lord@emf.net>
To: arch-users@lists.fifthvision.net
In-reply-to: <20030624140624.GB2899@doc.ic.ac.uk> (message from Andrew
        Suffield on Tue, 24 Jun 2003 15:06:24 +0100)
Subject: Re: tagging method design space (was Re: [arch-users] explicit tagging and tree-lint)
Sender: arch-users-admin@lists.fifthvision.net
X-BeenThere: arch-users@lists.fifthvision.net
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: arch-users@lists.fifthvision.net
List-Help: <mailto:arch-users-request@lists.fifthvision.net?subject=help>
List-Post: <mailto:arch-users@lists.fifthvision.net>
List-Subscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=subscribe>
List-Id: Arch users discussion list. <arch-users.lists.fifthvision.net>
List-Unsubscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=unsubscribe>
List-Archive: <http://lists.fifthvision.net/pipermail/arch-users/>
Date: Tue, 24 Jun 2003 12:15:19 -0700 (PDT)
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=AWL,BAYES_30,IN_REP_TO,KNOWN_MAILING_LIST,
	      MSG_ID_ADDED_BY_MTA_3,REFERENCES
	version=2.54
X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
X-UIDL: 566ad650b0184ccd93594c3618f9625d



    > From: Andrew Suffield <asuffield@debian.org>

    > What about the way that tag strings are currently generated in a
    > fashion that depends on the tagging method? We really need to be able
    > to describe the old tagging methods in a manner that doesn't change
    > all the tags. One suitable kludge would be an option that just adds a
    > fixed prefix, which we then set to 'i' for implicit, 'x' for explicit,
    > and so on.

I'm not sure why you think that such a kludge is needed.  The proposal
does not change the way in which those prefixes is determined.

(If you're thinking about the issue of "I want to change my embedded
tag into an explicit one, or vice versa..." -- that's orthogonal.)

    > [proposal:
    > 
    >   multiple sourc/precious/etc declarations, applied in order.
    >   an option for full-path matching.]


There's a slippery slope here between full generality (user writes a
little Scheme program to characterize each path or filename) and
efficiency.  So, the rule is (hereby) that, _in_principle_, it must be
possible to apply all of the namespace rules, built-in and
user-supplied, in a single regexp match (where the implementation is
free to use Rx-specific extensions and to rewrite user-supplied
regexps).

Your proposal satisfies that requirement (though, after some
profiling, I don't think I'll bother implementing it as a single match
-- there's still a bit of headroom there.)

There's a backwards compatability problem for existing =tagging-method
files.  

So I propose new directives:

        source-step  REGEXP
        precious-step REGEXP
        etc.

which are applied in order.

The existing directives `source', `precious', etc. are interpreted as
coming at the end of the list, in a particular order.

For paths:

        source/         REGEXP
        precious/       REGEXP
        etc.

and

        source-step/    REGEXP
        precious-step/  REGEXP
        etc.


where the / variants of the old directives are placed in the standard
order (exclude, junk, backup, precious, unrecognized source), after
the -step directives, but before the non-/ old directives.

The final "program" comes out as something like:

        unrecognized-step       "illegal-char-regexp"  [*]
        exclude-step            "control file regexp"  [*]
        source-step/            "control path regexp"  [*]
        precious-step           "++ regexp"            [*]
        junk-step               ",, regexp"            [*]

        < "*-step" and "*-step/" directives from =tagging-method >

        exclude-step/           "exclude/ pattern(s) from =tagging-method"
        junk-step/              "junk/       ''       ''         ''      "
        backup-step/            "backup/     ''       ''         ''      "
        precious-step/          "precious/   ''       ''         ''      "
        unrecognized-step/	"unrecognized/ ''     ''         ''      "
        source-step/            "source/     ''       ''         ''      "
        
        exclude-step            "exclude  pattern(s) from =tagging-method"
        junk-step               "junk        ''       ''         ''      "
        backup-step             "backup      ''       ''         ''      "
        precious-step           "precious    ''       ''         ''      "
        unrecognized-step       "unrecognized ''      ''         ''      "
        source-step             "source      ''       ''         ''      "
        
        unrecognized-step       .*                      [*]


where the [*] parts are built-in.

-t

_______________________________________________
arch-users mailing list
arch-users@lists.fifthvision.net
http://lists.fifthvision.net/mailman/listinfo/arch-users



From: Andrew Suffield <asuffield@debian.org>
To: arch-users@lists.fifthvision.net
Subject: Re: tagging method design space (was Re: [arch-users] explicit tagging and tree-lint)
Mail-Followup-To: arch-users@lists.fifthvision.net
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig"
Content-Disposition: inline
In-Reply-To: <200306241915.MAA01632@morrowfield.regexps.com>
X-Monty-Python: No-one expects the Spanish Inquisition!
User-Agent: Mutt/1.5.4i
Sender: arch-users-admin@lists.fifthvision.net
X-BeenThere: arch-users@lists.fifthvision.net
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: arch-users@lists.fifthvision.net
List-Help: <mailto:arch-users-request@lists.fifthvision.net?subject=help>
List-Post: <mailto:arch-users@lists.fifthvision.net>
List-Subscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=subscribe>
List-Id: Arch users discussion list. <arch-users.lists.fifthvision.net>
List-Unsubscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=unsubscribe>
List-Archive: <http://lists.fifthvision.net/pipermail/arch-users/>
Date: Wed, 25 Jun 2003 00:37:44 +0100
X-Spam-Status: No, hits=-14.4 required=5.0
	tests=AWL,BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,
	      KNOWN_MAILING_LIST,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.54
X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
X-UIDL: c6d3fa44e7ccb7eae25d141d182e04d5


--H+4ONPRPur6+Ovig
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 24, 2003 at 12:15:19PM -0700, Tom Lord wrote:
>     > From: Andrew Suffield <asuffield@debian.org>
>=20
>     > What about the way that tag strings are currently generated in a
>     > fashion that depends on the tagging method? We really need to be ab=
le
>     > to describe the old tagging methods in a manner that doesn't change
>     > all the tags. One suitable kludge would be an option that just adds=
 a
>     > fixed prefix, which we then set to 'i' for implicit, 'x' for explic=
it,
>     > and so on.
>=20
> I'm not sure why you think that such a kludge is needed.  The proposal
> does not change the way in which those prefixes is determined.
>=20
> (If you're thinking about the issue of "I want to change my embedded
> tag into an explicit one, or vice versa..." -- that's orthogonal.)

I was thinking more that by dropping the explicit/implicit thing in
favour of the more general scheme, this prefix would either change or
be dropped - which would change all the tags, and that's bad. If you
don't drop it, how is it determined which prefix to use?


The rest sounds fine; it'll fix all the problems I've faced with the
current system (unwieldy, can't match based on path). As for being
theoretically able to do things in a single match - that was one of
the constraints I was working with too.

Side note: it is moderately important that path matches be able to
distinguish between a file and a directory; this can be trivially
accomplished by saying that directories have a trailing /. Examples:

precious/ /foo$        Matches files called 'foo'
precious/ /foo/$       Matches directories called 'foo'

precious/ /foo/?$      Matches files or directories called 'foo'
precious  ^foo$        Equivalent (I think)

--=20
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'                          | Imperial College,
   `-             -><-          | London, UK

--H+4ONPRPur6+Ovig
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE++ODIlpK98RSteX8RAipxAJ9nNgvHX0A82NJGuutDcoUi+bIbvACdE7pA
lRDLLIWQVB3DM77IoymDszs=
=eUqS
-----END PGP SIGNATURE-----

--H+4ONPRPur6+Ovig--
_______________________________________________
arch-users mailing list
arch-users@lists.fifthvision.net
http://lists.fifthvision.net/mailman/listinfo/arch-users




* unprocessed:

From: Robin Farine <robin.farine@terminus.org>
To: auml <arch-users@lists.fifthvision.net>
Content-Type: text/plain
Subject: [arch-users] replay/update from sealed versions
Sender: arch-users-admin@lists.fifthvision.net
X-BeenThere: arch-users@lists.fifthvision.net
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: arch-users@lists.fifthvision.net
List-Help: <mailto:arch-users-request@lists.fifthvision.net?subject=help>
List-Post: <mailto:arch-users@lists.fifthvision.net>
List-Subscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=subscribe>
List-Id: Arch users discussion list. <arch-users.lists.fifthvision.net>
List-Unsubscribe: <http://lists.fifthvision.net/mailman/listinfo/arch-users>,
	<mailto:arch-users-request@lists.fifthvision.net?subject=unsubscribe>
List-Archive: <http://lists.fifthvision.net/pipermail/arch-users/>
Date: 24 Jun 2003 23:47:12 +0200
X-Spam-Status: No, hits=-15.8 required=5.0
	tests=AWL,BAYES_20,KNOWN_MAILING_LIST,USER_AGENT_XIMIAN
	autolearn=ham version=2.54
X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
X-UIDL: 58e3cded6599cdd8345c2621a14679b6

Hi,

If, for instance, I create a project tree with

  tla get lord@emf.net--2003b/dists--release-tla--1.0--versionfix-2 tla

and then I update the newly created "tla" directory with changes from
dists--release-tla--1.0--versionfix-3, this will add the patch log for
versionfix-3 to the project tree but won't update any source file.


Speaking of replay/update, I find the help messages a little confusing
in 'tla', I'm still heavily relying on 'larch' for --help :)

tla replay [options] revision dir [newdir] [version/revision]
                     ^^^^^^^^              ^^^^^^^^^^^^^^^^^^
                     ????????              [version|revision] or 
                                       [[archive/](version|revision)]?


[....]




# tag: Tom Lord Wed Jun 18 23:18:44 2003 (tla/=TODO)
#
