Re: [Gnu-arch-users] Archive metadata

[Scott Bronson]

On Fri, 2004-01-23 at 15:10, Tom Lord wrote:
> 2) Storing metadata as revisions is a good idea -- consider recording
>    the metadata in the log messages.

As discussed on IRC today, storing metadata in the log is
a decent solution to the closing/microbranching problem
(see PS below).

I'll use the word "close" instead of "seal".  Sealing is the
same as closing it because of a release.


The proposal:

When you close a tree, arch creates a patchlog entry that
describes your rationale.  For instance,

  "Tree-Closed: Merged, all changes integrated into
  address@hidden/dists--devo--1.0"

  "Tree-Closed: Abandoned, these changes were considered
  too hackish to live"

  "Tree-Closed: Cycled, development has moved to
  address@hidden/tla--integration--1.2"

  "Tree-Closed: Released, version 1.0!"

  (are there any other reasons to close a tree?)

Now, if you want abrowse to show only open projects, it would
fetch the last patchlog from each tree and display only those
that do not include Tree-Closed.  The performance hit should
be quite small.

Notice that committing to a closed a tree causes it to be re-opened
(because the last patchlog would not have a Tree-Closed entry).
This makes sense -- after you're done committing your fixes,
you would simply close it again.

So, would this be a good idea?

    - Scott


* The sealing problem: There are a number of different reasons
to want to seal a tree so there's minor disagreement about
how exactly seal should be used.  There's desire to stretch it
past its original design intent.

* The microbranching problem: because abrowse and rbrowse don't
provide any way of limiting or organizing their results, arch
tends to favor archives with 20-40 or so projects.  Beyond this,
it gets very confusing.  Therefore, arch users typically cram
multiple changes into a single tree and expect others to cherry-
pick the ones that they want.  If arch made it easier to have
an archive with hundreds of projects, developers would be
encouraged to branch more and merging would be simplified.  It
seems to be a matter of personal taste whether this is a problem
or not.