* KNOWN BUGS

** `larch.sh.in' should not add a libexec directory to PATH.

** star-merge should handle an additional case

   Given a project tree T from A, with B a branch from A, with no
   previous merging from B to A, star-merge should handle:

	star-merge perm{T,A,B}

** merge-points includes a continuation revisions patch in the
   list of merged-in patches.  That's enough for ordinary merging,
   but conceptually it should really recurse on the continued
   version and included merged-in patches found there, too.
   That would be horribly unreasonable, though -- that data 
   needs to be memoized in CONTINUATION revisions in archives
   at the time a continuation is created.

** the valid-log-file error messages given for an empty log message
   with header fields (i.e. the kind that make-log generates) confuse
   people.

** the "merged in" report for dists--release-ftp-utils--1.0--patch-4

  is wrong

** set-tree-version should be subsumed into tree-version

  By analogy to `my-id' etc.

** make-tag performance bug

  When tag commands reach the step "finding patches included in tagged
  revision", they take too long.  Lists of included patches should be
  memoized in revision directories to avoid having to read all those
  log files.


** too much code duplication: log file scanning

   There is an awk idiom used to scan log file headers that is 
   replicated or nearly replicated in many places.  It needs to
   be factored out (some versions have a bug triggered by an 
   unexpected EOF on input).

** make-library-browser

   patch-details needs to be recomputed for revisions that are 
   newly part of distributions (in order to pick up the distribution
   name as a "note").

** there's no (official, supported) way to remove unwanted 
   branches/versions/revisions from an archive.

   Versions should be tagged with a unique id so that stale patch
   logs don't cause confusion.

** star-merge doesn't ensure that the directory argument is the root
   of a project tree

  For example, `arch' contains a subdir named `arch'.  If I run
  star-merge in the root of the `arch' tree, instead of the parent 
  dir of that root, it merges into the subdir `arch', treating it as
  a project tree in which the subdir files have moved to the root, 
  and all other files and dirs been deleted.  I bet that `update'
  `replay', and `delta-patch' have similar bugs.

** push-mirror update ordering

  `push-mirror' currently honors transaction semantics within
  each branch, but does not make any guarantees about the ordering 
  between branches.  As a result, `push-mirror' can install a tag 
  before the tagged revision.  That can cause a `get' or other
  operation to (temporarily) fail.  The solution is probably something
  like noticing when a revision is a tag, checking whether the
  tagged revision is there, and if not, adding the tag revision
  and later revisions to the end of a queue, to be processed later.
  Versions might have to be requeued during queue processing.
  If a queue pass is completed without being able to install
  anything, something weird has happened.  If a tag refers to a 
  revision on a different archive, `push-mirror' shouldn't worry
  about it (though a multi-archive `push-mirror' would).

** temporary dirs and files aren't removed on detected errors

  When commands "exit NON-0", they sometimes leave around 
  temp files that should be removed.  To fix this, don't try
  to add "rm -rf" to lots of different code -- that won't work.
  Temporary files and dirs have to be "registered", then 
  cleaned up by "arch".  Best would be to replace "exit" with
  a sequence: "arch exitting $status ; exit $status" so that
  "arch" does *not* clean up temp files left when a bug 
  (unexpected abort) is hit.

** potential long lines in `notify'

  If there are too many new categories, branches, versions, or 
  revisions, `notify' will try to execute command lines that
  are too long.  Given the semantics of `notify', it is ok to
  break long command lines into multiple invocations, though.
  This could be fixed with a trivial `xargs', but a better fix
  would be to update the recipients status file after each 
  batch.

** `arch add dir1 dir2'

   puts a tag for a file named dir2 in dir1

** arch should be able to run from the build directory

** the name `arch' conflicts with /bin/arch on some systems

** file-diffs use of `file-list --root' is wrong

  dates from the days when file-list generated file: method URLs
  and thus should be fixed.

** update --in-place is using --cache ineffectively

   (this is somewhat less serious now that libraries are up.)

** dopatch -- automatic ChangeLogs with no patch log

  Currently, these are left quietly unmodified.
  In fact, the .patch file should be applied to them.

** push-mirror status bug

  In push-mirror, some commands are piped into sort.  The status
  of those commands matter.  Perhaps a "pipe" shell tool would
  be a good idea -- one that checks the exit status of both
  commands.




* TESTING

** a test suite

  It is practical (I'm guessing about the equiv of 1 or 1.5 man year,
  but highly parallelizable) to make a *comprehensive* test suite that
  exercises all interesting cases of every command, resulting in an
  exceedingly reliable system.

  Given the nature of revision control (it's mission critical), making
  such a test suite would be a good investment, if you think `arch'
  is a significant improvement over `CVS'.  (My view is that `arch'
  is fundamentally the right approach -- the final word in revision
  control.)

  How I got 1 man year: there are around 70 commands.  Many of these
  are very trivial and easily tested -- let's guess 1/2.  By "easily
  tested", you could write the tests for two of them in one day, with
  time for two beers at lunch.  So:

	35 easy-to-test commands:	13 days

  Of the "hard to test commands", I'll guess an average cost of about
  3.5 days each to write the tests.

	35 hard-to-test commands:	122.5 days

  I plan based on 120 work-days per man/year.

  One obstacle to parallelization is the need for a common test
  framework, but I've got one of those from `libhackerlab'.  Another
  obstacle is creating shared test data (sample project trees) -- but
  the pay-off is making tests easier to write.  (In my scratch files,
  not in the distribution, I've got the start of a mechanism for
  organizing test trees and automated edits.)  The expected progress
  is below the goal rate at first, then faster than the goal rate once
  the infrastructure and shared test cases are in place and mastered
  by the test writers.  I'm guessing 4-6 months with 3-4 people,
  higher quality (but not more speed) if others contribute tests after
  the infrastructure is up and documented.

  The time estimates are entirely separate from the activities of
  fixing the discovered bugs, enhancing arch, writing more
  documentation, etc.


** FTP testing

  Every FTP server seems to have its own screwy ideas about mapping
  RFC959 to unix.  Testing `with-ftp' against a variety of servers,
  hitting edge cases like empty directories and non-existent files
  is desirable.  Things to watch for: `NLST' not including directories
  unless you give it an argument.  `NLST' and `LIST' doing weird
  things with arguments (interpreting them as `ls' flags, for
  example).  `NLST' returning an error for an empty directory.

  A separate `with-ftp' test suite, runnable against a farm of
  different servers, is desirable.  So too is running the (eventual)
  `arch' test suite against all those servers.

  It would also be worth reading the source code of various servers
  to make sure that they rename files with `rename', rather than by
  calling or emulating `mv':  that's critical to the correctness of
  the locking algorithm used by `arch'.

** porting

  I use FreeBSD and have very limited access to (an old version of)
  Linux.  A test suite would help with testing ports, but just
  informal testing ("build it and try it") would be a big boon.



* DOCUMENTATION ISSUES

** user's guide needs review/editting/completion

  The user's guide is a bit crude.  It needs a good review/edit and is
  missing documentation of some commands/options.  The most particular
  problem is inconsistent use of terminology.

** reference manual needed

  An encyclopedia-style referece manual is needed (i.e., one chapter
  per group of commands; one section per command; glossary).

  Most of the reference manual should be automatically generated from
  help messages (output of "--help") -- though the help messages might
  need some clean-up for this purpose.

** help messages too long

  There should be two help options: -h which shows only the
  options, and --help which shows the complete help message.
  (This is easy to add to the existing code).

** toc's and menus should have descriptive text

  In addition to chapter or section headings, a brief description,
  as in `info' menus.  This requires changes to the documentation
  processor, which could, in fact, do with a complete rewrite.




* CVS UPGRADE PATH

  Here's three plans.  Take a CVS directory (a tree of CVS controlled
  files).

		    PLAN 1 (based on log messages)

  Start with the earliest revision of the tree.

  `import' that to arch.

  REVISION LOOP:

  Looking at the "next revision" of the individual files, group them
  into equivalence sets based on log messages.

  Of those equivalence sets, pick the one with the earliest time
  stamp (based on the first-checked-in-file in the set).

  Update the files in that set to the next revision.

  `commit' to arch.

  goto REVISION LOOP


		   PLAN 2 (based on full-tree tags)

  `import' the earlist tree revision to arch.

  For every CVS tag applied to the entire tree, get that revision and
  `commit' to `arch'.  Optionally create a corresponding tag in
  `arch'.


			   THE PERFECT PLAN

  The "perfect plan" combines the two approaches.  That is, it runs
  PLAN 1, however, whenever a tagged revision falls between two
  log-based revisions, commit that tag-based revision and maybe add a
  tag.  If a CVS-tag-based revision crosses the boundary between two
  or more log-based revisions (which is possible in CVS since tagging
  and committing are not atomic), pick an arbitrary ordering of the
  revisions and put a warning in the log message (that the deltas
  around this point may be confusing).


  Note: one user suggested a need to convert CVS tags of
  subdirectories (and, presumably, individual tags).  That
  doesn't change the above plan very much.



* GUI

** project tree manager

*** color-coded inventory listings

*** passive-recognition interface to `arch' commands

*** status indicators

*** visual diff launcher

    This is easy to do against the ancestor revision;  slower against
    an arbitrary revision until individual file retrieival is added.

** branch manager

   The output of `arch merge-points VERSION' for several different
   (presumably related) branches defines a directed graph.  Drawing
   this graph (illustrating merge points) is useful.  It would also
   be nice to select branches and revisions by pointing, for various
   `arch' operations.



* INTERNATIONALIZATION

  The relied-upon shell tools have to done first.  This work is
  actually taking place, though.

  In the scripts, `printf' should be replaced by `msg', which has
  mostly the same CLI, but optionally looks up its format string in a
  translation database.   Multi-line messages (made by repeated calls
  to `printf') should be printed by a single call to `msg', so that
  they can be translated all at once, rather than line-by-line.



* BRANCHING AND MERGING

** arch log-skipped

  Make a log entry recording a particular revision delta as skipped.
  This is for reverting patches without confusing history-sensative
  merges.  (E.g., instead of applying `patch-10', just add a
  ``REVERTED'' log message for `patch-10'.)

** idempotent merging

  After finding `star-merge', I'm less convinced idempotent merging is
  really needed.  But here is what it does:

*** i-merge

  Form a merge by an arbitrary combination of lower level merge
  commands (`update' `replay', `reconcile', `star-merge').  If no
  conflicts occur, that merge can be committed as an "idempotent
  merge" -- later merge operations can skip this patch set (except for
  the log message) if they already have all the paches merged in.

  The problem is, what if there are conflicts?  A complementary tool
  would let you resolve the conflicts, complete the merge (but not
  commit), then compute a new tree, which is sans-the-merge, but with
  the conflict resolutions in place (somehow).  Then you commit that
  weird tree.  Then the idempotent merge works cleanly.  Doesn't
  `star-merge' (and `reconcile' in a pinch) seem much simpler?

  If `i-merge' happens, complementary commands needed include:

**** commit --idempotent

**** update --partial




* PREPARE-DETACHED

  If you know you'll be off-net and want to work with remote
  archives, this command should help.  For example, before a
  complex merge, `prepare-detached' for the relevant branches.

** cache remote deltas/log files

** compute/add/lock whatever pristines are needed

** optionally also lock revision tips in the archive



* PERFORMANCE IMPROVEMENTS

** library-add is lockless

  Concurrent invocations of `library-add' will waste lots of cycles
  and locks would fix that.


** add a profiling option

  Add a mechanism to `arch' which invokes each command with `time',
  logging the results.  Then a tool that processes the logs to
  generate relative amounts of time spent in each subcommand (keep the
  time logging overhead low).  Use this to decide what should be in C,
  or which commands are too poorly supported by the repository and
  project tree formats.

** tree-lint seems to take too long when there are large nested sub-trees.

  Probably -prune isn't being used right.

*** speed up `merge-points'

  This is fine for now, but if it has to search several hundred log
  entries, it will be too slow.   There's lots of head-room in the
  rather brute-force implementation, though.

** support forward/backward patching, patch combining

  One point of switching to unified diffs was to be able to pick up
  the patchutils to be able to do composition and inversion of patch
  sets.  Inversion could be handled in `dopatch' without modifying the
  patch set itself, but being to modify the patch sets will be useful
  in many contexts.


** add a way to use arbitrary cached inventory in mkpatch, dopatch, tree-lint

   DONE: mkpatch, dopatch
   TODO: tree-lint

** caching improvments

** fast update --in-place

  [This is out of date.... using revision libraries, there is a
  simpler solution.]

  Right now, `update --in-place' makes an entirely new project tree,
  renames the old tree to "<something>.bak", then puts the new tree
  where the old tree was.  There's a faster way, described below.
  (On the other hand, `replay --in-place' really does modify the
  existing tree.)

  equiv to:

	local_changes = delta (ancestor, tree)
	to_get_latest = delta (tree, latest)

	tree <- to_get_latest[tree]
	tree <- local_changes[tree]

  In other words, logically, patch the tree to the pristine state of
  the latest revision, then apply the diffs from the ancestor to the
  pre-patched tree to the patched (i.e. latest revision) tree.

  The patch set `local_changes' is easy to compute quickly -- by
  comparing the tree to its cached ancestor.  But what about
  `to_get_latest'?

  "easy" to compute:

	latest_changes = delta (ancestor, latest)
	rev_local_changes = reverse (local_changes)
	to_get_latest = latest_changes o rev_local_changes

  where `latest_changes' is the composition of all the patch sets from
  the ancestor to the latest revision in the archive.  (All of these
  patch sets are in the archive.)

  One nice thing about the slow implementation of `update --in-place'
  is that it's easy to recover if the command is interrupted or if you
  change your mind after seeing the results.  A faster implementation
  should try to preserve those properties.

  roughly:

	compute latest_changes -- stash in a safe place
	compute to_get_latest
	mark tree as hosed
	apply to_get_latest
	mark tree as not hosed, but sans local changes
	apply local changes
	mark tree as updated

	provide an `undo' operation to restore latest
	changes

  With that, though, you can still wind up with the tree in an
  intermediate state if you interrupt a command.  A "perfect" solution
  would be to modify "dopatch" to optionally log all changes as they
  are made, and to make sure that the changes to the file system are
  (in the context of the log) reversible.


** more extensive tree index caching

  Suppose you `get' a revision.  There's a full-source base revision
  or cached revision, followed by umpteen patches.  `get' is a bit
  slow as it plows through those patches.  What are the solutions and
  what are not the solutions?

	* Combine all the patches on the client side and apply them
	  all at once.

	  My guess is that this is a non-solution.  Combining the
	  patches isn't much less expensive than applying them (except
	  for index computation -- see below).  May as well apply them
	  one at a time.

	* Combine all the patches on the server side and apply them
          all at once.

	  If you are running remotely, this will probably cut down on
	  network traffic.  It would require a custom server -- not
	  just an FTP server.  If the patches are mostly orthogonal
	  (each patching a different set of files), the savings will
	  be small, though, and this adds a fair amount of complexity
	  on the client side.

	* Avoid re-computing tree indexes.

	  My guess is that this is the biggest, easiest speed-up
	  available.  Every time you call `dopatch', it computes
	  `arch inventory' of the tree being patched.  Just reading
	  all those directories, for a large project, is noticably
	  slow.  Fortunately, after the first patch in a series of
	  patches, this work is redundant:

  dopatch computes final indexes now (the tree index after patching).
  It should optionally return these indexes and accept ----*indexes
  command line options. build-by-patching should relay index files
  between successive calls to dopatch and optionally leave an index
  for the caller.  get should save that index in the pristine tree
  index cache.

  separate pristine chaced indexes are needed for dirs and files.

  speed up index computations by having inventory print "D " for dirs,
  "F " for files with one traversal.


** auto-cache every Nth revision (20) in commit

** write a native version of `inventory'.

  I'm not sure this would really win or win enough to be worth the
  maintenance head-ache.  `inventory' is the biggest invocation of
  `find' you are likely to see this year.  Worse, for some parts of
  the find expression, `inventory' invokes a sub-process (e.g. to compute
  inventory tags).  A single-process `inventory' should be much
  faster -- but faster enough to be worth the trouble?

  At some point, you run into the brick wall of the cost of the system
  calls for reading directories and scanning file contents for tags --
  that's the lower bound.



* CONFIGS

** recursive what-changed

  Given a multi-project tree, instead of running what-changed for
  every sub-project, it would be nice to be able to run a recursive
  what-changed that generates a grove of patch-reports, linked to by
  a top-level index file.

** recursive commit

  I'm not sure that this command is a good idea, user-interface-wise.
  It might be too easy to make mistakes with it:

  arch commit-config [--recursive] [--latest] name

	with --recurse, commit all the subtrees (but with what log files?)
	then `snap-config' configuration `name' (--from-tree default)
	then commit the config dir

*** log files possibilities for recursive commit

**** interactive (with what-changed help), or

**** =TODO formalization, or

**** require the user to `make-log' in each subdir first


** recursive tag?

   Given a multi-package tree, it would be convenient to be able
   to generate a tag for all the revisions in the tree.  You can
   do this now using `inventory --trees --nested' together with
   `xargs' and some other commands, but maybe that idiom should be
   captured in a single command.

   In the arguments to that command, how do you specify what branches
   tags go on?  Should all trees be tagged in a version with their
   current category and version number, but a branch label specified
   to the recursive tag command?  Or something trickier?



* NAMES CAN'T HAVE GLOBBING CHARACTERS

  inventory(DONE)/valid-*(TODO) should enforce this



* MICRO-ARCH

  What would it take to factor `mkpatch' and `dopatch' (and their
  dependencies) into a separate distribution?  For one thing, it would
  take an alternative (slower) version of `inventory' that does not
  depend on the `file-utils'.

  With a tiny distribution, people could include `mkpatch' and
  `dopatch' with other packages, providing a standard way for
  non-arch-using contributors to submit or apply patches.



* BASIC FUNCTIONALITY TOUCH-UPS

** valid-log-file should be parameterized

** update-distribution and distribution-name have inconsistent options

   update-distribution should take a --dist option, rather than a 
   positional parameter

** email messages generated by notify should have an extra header

  X-arch-notify: FOO

  which can cause an automated recipient to invoke:

	arch notify DIR FOO

** --pull option to push-mirror
  
  `push-mirror' makes a persistent with-ftp connection to the 
  destination server.  It should have a flag to override that.
  It should also just notice of one server is "ftp:" while
  the other local.  Or, it could juggle two with-ftp connections.

** push-mirror argument ambiguity

  push-archive is a good example of the ambiguities caused
  by a name that could be a category or a branch.  push-archive
  just assumes it is a category, but there should be a syntax
  that disambiguates the matter.

** need an `update-log-message' command

   You should be able to do something like:

	% arch retr-log patch-level

   which makes a ++log* file for a specific, past log message,
   containing that log message (sans extra headers).

   Then edit the message and:

	% arch commit-log-change patch-level

   which will: (1) create a unique pointer file in the archive
   for the old revision ("patch-level") pointing to a 
   corresponding name in the eventual archive revision dir
   for the new revision -- for readers, the link might
   point to a non-existent file, or might not, but most readers
   can ignore the link entirely.
   (2) commit a patch set which modifies only 
   that log file and the automatic changelogs, plus adds
   a new log file (which can be automatically generated by 
   default).  The revision dir for this commit should include
   the modified log entry.  Then add an option to "revisions
   --summary" and "cat-archive-log" which looks for revised logs.
   (3) if the commit fails, remove the link file from the old
   revision directory.   Note that if the log is from an archive
   other than the one where the change is being committed, you
   must have write access to both archives or commit-log-change fails
   at step 1.


** notify email message improvements

   Add an option to put full log messages in notify messages.

   Add an option to add archive =README files to notify messages
   for new categories, branches, and versions.

** arch.sh.in needs --debug

   to invoke commands with -x set. 

** do we want commands to check in or get individually selected files?

   Checking in selected files from a larger tree is easy to implement
   already.  I've resisted providing this feature because I think it
   is too dangerous (as when people use the command because it is
   fast, but forget to check in related changes).  Is my judgement 
   right about that?

   Checking out selected files will become easy to implement as the
   fast revision history browsing features come on-line.  This is
   something I'm more likely to include.  (However, checking out
   selected files this way won't effect the patch log of the tree;
   it will be equivalent to hand-editting or creating the files,
   setting their contents to be the same as in the earlier revision.)
   

** need a command to remove unwanted patch logs

** valid-package-name

   /version passes the test for a valid package name.  Should be
   rejected for having an empty archive identifier.

** star-merge

*** are precious files reliably copied to output directories?

** tree-latest --all?  tree-history --url?

   Generally, better command-line browsing for a tree's browse/merge
   history is desirable.  `log-ls', `cat-log' and `whats-missing'
   are a little bit too low level.

   NOTE: `merge-points' pretty much does the trick.  Still,
   visualization of the output of `merge-points' would be a big
   help.

   Here's an obscure reference:  In the `notes/guis' directory of the
   Subversion source code, there are screenshots of a ClearCase
   gui that draws a graph of revisions, with links showing
   branch points and merge points.  In ascii, its roughly like:


	 branch-A
	    |---------------
	 revision	    |-----------> branch-B
	    |			             |
	 revision		       .  revision
	    |			     ..	     |
	 revision<..   	     	  ...	  revision
	    |	    ..............	     |
	 revision			  revision
	    |			             |
	 revision     ...........	  revision
	    |	    ..		 ..          |
	 revision...		   ....>  revision


   Where the "dash arrow" (black arrow) indicates a branch point
   and the "dot arrows" (red arrows) indicate merge points.
   Merge arrows splined upwards indicate merges from right to left,
   merge arrows splined downwards indicate merges from left to right.
   You can selectively hide or reveal particular sets of arrows.

   Then (presumably) you can select revisions by clicking and perform
   various operations on them.   

   The dot arrows in diagrams such as that fall directly out of the
   output of `merge-points', run once for each branch being graphed.
   The dash arrows fall out of looking for CONTINUATION files in the
   archive or "Continuation-of" headers in log messages.
   
   Graph layout is pretty trivial to automate.

   There's some trickiness doing this well for `arch' since a 
   merge doesn't necessarilly include a contiguous selection of
   patches -- so the butt end of red arrows may sometimes have to
   splay out to indicate a specific, peculiar set of revisions.


** log-ls argument processing (e.g. branch instead of version)

   In this case, a branch name should mean -- list for all versions.
   A category name - all branches/versions.  See the notes below
   about "ambiguities with names".


** way to remove empty versions and branches from an archive

   The whole point of a three-step process for creating a new
   version in the archive is to increase the chance of noticing
   mistakes early -- so you can delete the bogus category, branch,
   or version.  But there is no command yet to actually do that
   delete operation.


** dopatch

*** dopatch needs to set directory permissions on new directories

*** bogus patch sets can effect mischief


** review command syntax

*** accept [archive/]revision everywhere

*** accept branch or version meaning latest revision everywhere

    This has to be done carefully, though.  Computing the latest
    version or revision from a branch or revision name requires
    looking at the archive.  There are some commands that need
    a version or revision specification that don't have to 
    look at the archive.   If you give an abbreviation to one of
    those commands, and the archive can't be reached, you should
    get a helpful error message suggesting that you use a full
    version or revision name.

    Trickier, though, is if the archive *can* be reached, but
    remote access is slow.  In that case, it would be nice to
    remind the user it isn't necessary -- but I don't know of a
    clean way to detect the situation or report the advice to
    the user.

*** valid-package-name and parse-package name clean up

   These commands need a little bit of work -- the earlier it
   happens the better since these commands are likely to be used
   by (complex, user written) scripts that use `arch'.

**** regularize option names, pick better names in some cases

**** fix ambiguities with names

	category

		is that the category generally, or
		the null label branch?  (e.g.
		what list does ``arch pristines category''
		print?)

	category--branch
		is that the latest version, or all
		versions?

	category[--branch]--version
		is that the latest revision, all revisions,
		or the version revision, or the latest
		version/versionfix revision with an error
		if neither exists?


***** disambiguators

      Here are some proposed disambiguators.  Unfortunately,
      some of these require server round-trips to parse.

      arch pristines needs this for limit_branch

	category
		in contexts that require just one branch,
		this always means the null-label branch

		in contexts that permit any number of branches,
		this always means all branches in CATEGORY

	category--
		always means the null-label branch

	category--branch
		in contexts that require just one version,
		this always means the latest version

		in contexts taht permit any number of versions,
		this always means all versions in CATEGORY--BRANCH

	category--branch--

		always means the latest version

	category[--branch]--version
		in contexts that require just one revision,
		this always means latest revision.

		in contexts that permit any number of
		revisions, this always means all revisions.

	category[--branch--version--

		always means the latest revision

	category[--branch]--version--v

		(literal "v") in conetxts requiring just one
		revision, the version revision.

		in contexts permitting any number of revisions,
		the version revision and all versionfix revisions.

	category[--branc]--version--v.

		always the version revision

	category[--branch]--version--vf

		(literal "v") in conetxts requiring just one
		revision, the latest version or version fix revision.

		in contexts permitting any number of revisions,
		the version revision and all versionfix revisions.

	category[--branc]--version--vf.

		always the latest version or versionfix revision


***** modifiers

    appended to any specification for a single version:
	/+<n>
	/-<n>
		the nth following or preceeding version

    appended to any specification for a single revision:
	/+<n>
	/-<n>
		the nth following or preceeding revision
		(in the same version)


** arch browse CMD arguments

   In a user configurable way, pass the URL output by CMD
   to the user's browser.  I use a script "browse", not included
   with `arch', that is simply:

	#!/bin/sh

	netscape --remote "openURL(`\"$@\"`)"

   That should be generalized and added to `arch'.


** link to original and modified trees in patch-report --html

   For each patch, optionally link to both the original and modified
   files.  Somewhere on freshmeat is a web hack that does the usual
   side-by-side color-coded diff listing using tables.

   Options like --original DIR and --modified DIR.


** support html output (--html) in:

   For the purposes of generating nicer reports from automated 
   processes, these commands should be able to generate html
   in addition to the usual outline format output:

	   import
	   get
	   commit
	   update
	   replay
	   star-merge

	   others?


* MECHANISM FOR CHANGING TAGGING METHOD

  Changing tagging methods after creating revisions results in
  ridiculous patch sets (gratuitous adds/deletes).

  Simplest solution is: "so what - you should pick the right
  tagging method to start with".  But maybe a fancy solution
  is practical.

  A fancy solution would be nice for this scenario:

	1. Someone publishes a series of distributions
	   of some package.  I want that series under local
	   version control.

	2. Their files don't have `tag:' lines or `.arch-id'
	   directories, so I use the ``names'' tagging method.

	3. I have local changes that I (re-)apply to each new
	   revision.

	4. After several revisions, they add `tag:' lines to
	   their files.

  But the problem is:

** what is build-by-patching supposed to do (for example)

** is tagging-method an optional part of the patch format?



* INCREMENTAL PROJECT TREE BACK-UPS

  Investigate rdiff-backup (freshmeat) as a buffer between working
  copies and the archive.



# tag: Tom Lord Thu Jan 10 00:54:01 2002 (arch/=TODO)
#
