Inactive branches should "fade away"

That's an intriguing suggestion.

It would have to be done in a way compatible with bug 79493 (highlight important branches).

My gut feeling is that branch which had no new revisions (per branch scanner) in "some time" could be marked with an extra attribute, to preserve the user-specified status. I am not sure how that should be displayed in the UI.

On 16 Jan 2007, David Allouche <email address hidden> wrote:
> That's an intriguing suggestion.
>
> It would have to be done in a way compatible with bug 79493 (highlight
> important branches).
>
> My gut feeling is that branch which had no new revisions (per branch
> scanner) in "some time" could be marked with an extra attribute, to
> preserve the user-specified status. I am not sure how that should be
> displayed in the UI.

Yes. I talked briefly with Tim about this yesterday.

I think they could be displayed in any of these ways:

 * pushed to the bottom of the list
 * showed faded out (eg with text in 80% gray not black)
 * hidden by default unless you choose a "show inactive branches" option

The first two would probably only be understandable if you have an
indication of when the branch was last modified.

I think for these purposes it would be ok to take the last change date
as either

 * the date of the last revision
 * or the date the branch was last seen to change

whichever is easier. The case of a branch which is updated by pulling
very old revisions is negligible.

--
Martin

Given the fact that branches are scanned only when there is new data available as identified by the branch scanner, the last scanned time could be used to filter inactive branches.

Perhaps a gradiant:
 - Branches where last scanned was over a month ago get grayed out.
 - Branches where last scanned over three months ago get 'marked' as inactive, and not shown by default.

Here is one way we could handle the marking:
 - Provide a different property that we use to filter on rather than 'pure' lifecycle status which can override the lifecycle status to 'inactive', and we use that for display and filtering. That way we can have a selector for Inactive, and if the branch gets reactivated, then no changes are necessary for the branch reactivates.

Graying out older branches could be handled by simple CSS attribute that we can then use to change the default font later.

We would also want to handle the case where branches are told not to get mirrored where they might be there just for registration purposes.

That way these branches wouldn't suddenly disappear. However we do need to consider what should be done about these, as they may also be stale.

On 16 Jan 2007, Tim Penhey <email address hidden> wrote:
> We would also want to handle the case where branches are told not to get
> mirrored where they might be there just for registration purposes.

Is that supported at the moment?

--
Martin

Martin Pool wrote:
> * pushed to the bottom of the list
> * showed faded out (eg with text in 80% gray not black)
> * hidden by default unless you choose a "show inactive branches" option

That's tricky. I would like to hear mpt on this.

> I think for these purposes it would be ok to take the last change date
> as either
> * the date of the last revision
> * or the date the branch was last seen to change
> whichever is easier. The case of a branch which is updated by pulling
> very old revisions is negligible.

The use case I'm concerned about, admittedly a corner case:

 * User create a new team branch from an existing inactive branch. At this point the branch has no recent revision, but is "hot" because it's the place for contributors to put new stuff.

More abstractly, if a branch is created/pulled from another old branch, it appears likely to receive new interesting content soon. In particular, if the branch is a team-owned upload branch it should be easy to find because it gives instructions for upload.

Martin Pool wrote:
> Tim Penhey wrote:
> > We would also want to handle the case where branches are told not to get
> > mirrored where they might be there just for registration purposes.
>
> Is that supported at the moment?

Not explicitly, but its is the use case for existing mirror branches with sftp and bzr+ssh URLs.

The initial plan (back to the supermirror inception) was something like:
 * Not provide an explicit "do not mirror" flag
 * When mirroring fails, increase the interval between attempts.
 * After a number of failed attempts (e.g. 10), no longer attempt to mirror
 * Allow user to explicitly request mirroring.

On 17 Jan 2007, David Allouche <email address hidden> wrote:
> Martin Pool wrote:
> > Tim Penhey wrote:
> > > We would also want to handle the case where branches are told not to get
> > > mirrored where they might be there just for registration purposes.
> >
> > Is that supported at the moment?
>
> Not explicitly, but its is the use case for existing mirror branches
> with sftp and bzr+ssh URLs.
>
> The initial plan (back to the supermirror inception) was something like:
> * Not provide an explicit "do not mirror" flag
> * When mirroring fails, increase the interval between attempts.
> * After a number of failed attempts (e.g. 10), no longer attempt to mirror
> * Allow user to explicitly request mirroring.

OK, I think that's compatible with this request and the others I just
filed:

If the branch is not mirrored, that should be brought to people's
attention, eg with a badge, so that they can fix it.

If after a long period of time we never manage to get to the branch, it
should fade away so as not to clutter the display with stub objects.

--
Martin

I like this idea. I have nothing particularly useful to add, except that if different color/size is used to indicate age, it should be a gradual scale (using a style= attribute with computed values), because a sudden change at an arbitrary age would look like a bug rather than something deliberate.

I have a branch in progress that adds a date_last_modified to branch that we can use to drive the opacity.

This wish may come true :-)

Fixed in RF 5481.