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

[David Allouche]

On Thu, Jan 22, 2004 at 11:03:15AM -0500, James Blackwell wrote:
> > 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.
> >
> > 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.
> 
> Two questions:
> 
> 1. Would you plan to include this Seal line in every versionfix
> patchlog?


Yes, but it would be a duplicate of the Seal line in the version-0.

It does not make sense to fix a closed or cycled version since, by
definition, no further work needs to be done on closed versions and all
further work on cycled versions is done somewhere else. Actually, I
think a safeguard should be added to "commit" and "tag" to prevent
adding to a closed or cycled version.

> 2. If only version-0 has a Seal: line in the patchlog, but we were at
> version-6, would that mean we'd have to get all of the patchlogs and
> then go back 6 patchlogs to look to see if Seal: is there?

I assume you mean verionfix-6.

Check the step 1 of my algorithm, you need only check the log if the
last revision is version-0.

> 3. How much of an impact do you think this would have on the running
> time of rbrowse?

At most one cat-archive-log per version. This worst case happens if:

  1. All outdated versions are consistently closed.

     This is questionable, generally one is only interested in the
     oldest version for a given category. Except for symbolic tag
     branches, but they are comparatively few.

  2. All released versions had no fix.

  3. All other versions were cycled.

The relative importance of these points may vary with the way arch is
used.

Also count in that log files for cycled and closed version are very
small.

Assuming the running time of abrowse is dominated by network lag and all
commands are run synchronously that could probably have significant
impact on the running time. Maybe as much as +75% on worst case.

Though, since abrowse essentially does a tree traversal, it might be
possible to use several asynchronous connections to inspect different
branches, so the bottleneck would become bandwidth. But the extra
complexity is most probably not worth it.


PS: there are three kinds of people:
    those who know how to count and those who don't ;)
-- 
                                                            -- ddaa