gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Making microbranches popular


From: David Allouche
Subject: Re: [Gnu-arch-users] Re: Making microbranches popular
Date: Thu, 22 Jan 2004 13:01:55 +0100
User-agent: Mutt/1.5.5.1+cvs20040105i

On Thu, Jan 22, 2004 at 04:01:04PM +1100, Robert Collins wrote:
> On Thu, 2004-01-22 at 08:22, James Blackwell wrote:
> > I fixed rbrowse so that sealed trees are not seen by default. Then I
> > sealed all of my old branches. I was (and am) very, very happy with the
> > results.  I was so happy with the results that I rushed a merge request
> > to Tom. 
> 
> I have a problem with it, now I've actually got time to breath...
> 
> sealed branches are 'released', not 'obsolete'. They have a clear
> semantic, and have had for ages.
> 
> Your patch abuses that semantic.

First of all, I am happy to see that some people actually agree with me
that version-0 and versionfix-N revisions are still useful to something.

Then, I agree both with James and Rob: I actually use version-0 _both_
for _released_ versions (according to the initial intent of sealing) and
for _closed_ versions, e.g. when cycling archives.  The problem is
pretty much that (while some think sealing is obsolete and useless)
sealing is actually overloaded to mean either "released" branch, which
should not be hidden, or "closed", which it may make sense to hide.

Actually, when thinking a bit more about it, I think we can identify
_three_ use cases: "released" (original intent), "closed" (microbranch),
and "cycled" (continued in another archive). The only case where the
version should be hidden is "closed".

It seems that these states are mutually exclusive, though I am not too
sure about "released nand cycled". If we can agree that these states are
exclusive it is possible to design a simple set of rules to sort them
out:

  0. last rev is base-0 or patch-N -> version is open
  1. last rev is versionfix-N -> version is released
  2. last rev is version-0
    2.a: version-0 patchlog has "Seal: closed"
         -> version is closed and hidden by default
    2.b: version-0 patchlog has "Seal: cycled address@hidden"
         -> version is cycled to the named archive
    2.c: version-0 patchlog has not "Seal" header or "Seal: release"
         -> version is released

The "Seal:" header provides hints for tools. For abrowse to show or not,
for merge tools to display a warning when merging with a cycled branch,
etc.

So far, this proposal does not seem crufty at all to me. What follows is
more problematic.

In the case of a cycled version, the archive name is intended to be a
hint directed at the user. The full version name is not given so we do
not end up with an easily brokn reverse-tag feature. Though, it may be
deemed useful to provide an extra command which could set the full
continuation version:

  tla cycle [-d TREE] TO-VERSION

  TO-VERSION is a not-yet existing or empty version (in another archive)

  The TREE (defaults to the current tree) must have no pending change.
  Its version is sealed (version-0 is created), and a base-0 tag to this
  new revision is created in TO-VERSION. If needed, TO-VERSION is set up
  first.

This would be only user-visible command which could create revisions
with "Seal" header specifying a full version name. By wise use of
locking we may try to avoid ending up with a an inconsistent "Seal"
header value, but I see no way of making it really bulletproof.

-- 
                                                            -- ddaa




reply via email to

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