* 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 Thäter) 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 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: List-Post: List-Subscribe: , List-Id: Arch users discussion list. List-Unsubscribe: , List-Archive: 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 = 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 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: List-Post: List-Subscribe: , List-Id: Arch users discussion list. List-Unsubscribe: , List-Archive: 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 > 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 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: List-Post: List-Subscribe: , List-Id: Arch users discussion list. List-Unsubscribe: , List-Archive: 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 >=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 To: auml 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: List-Post: List-Subscribe: , List-Id: Arch users discussion list. List-Unsubscribe: , List-Archive: 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) #