Re: [Monotone-devel] Re: Problems with _MTN/tmp

[Nathaniel Smith]

On Thu, Jun 01, 2006 at 08:32:49AM +0200, Johan Bolmsjö wrote:
> I'll be constructive this time. Some features from CC that I find useful.

Yay, constructive comments are always really helpful :-).

> - Obsoleting branches.
> 
> If you are a bunch of people working on a project and use feature branches 
> you 
> will end up with a ton of branches that have been merged back to the main 
> project branch and are not really that interesting. E.g. "mtn ls branches" 
> list all branches. Maybe it would be nice if you could mark/unmark a branch 
> as obsolete. Just to not see it when doing day to day work. I know in 
> monotone you can create a new repository and just pull the branches you want 
> to keep (I'm not sure if this pulls contributing branches). But this is more 
> work since you have to keep a master repository somewhere to keep the entire 
> history.
> 
> Properties of obsoleted branches:
> - Read only (can not commit to them, might be a problem with monotones 
> distributed nature, although if someone has commited to a branch you have 
> obsoleted the other guy has effectively marked it as non obsolete)
> - Invisible for "mtn ls branches" if you do not specify otherwise.
> - Mostly invisible in the clearcase version tree browser for a file (just a 
> little arrow head at file versions where this branch has been merged to (not 
> too obtrusive).
> 
> - Renaming tags and branches.
> 
> Sometimes you make mistakes and rename is always good to not make you nervous 
> when you decide on a branch/tag name. I've seen maybe this will go into 
> monotone some day.

Oh, wonderful!  These are exactly two of the use cases that we're
trying to work out a design for :-) (I'm thinking of the work on
"management branches" or "versioned policy" or "whatever clever name
we eventually settle on".)

For the curious, there are some working notes scribbled down on the
wiki:
  http://venge.net/monotone/wiki/VersionedPolicy

> - Version tree browser.
> 
> Even if it's slow at displaying files where you have many versions. It's a 
> powerful tool to visualize the branches and merges for a file/directory.
> If you find a bug the version tree browser easily let you find out where this 
> change occured. I know graphical tools are not part of "core" monotone. 
> Anyone can make a really good version browser:-) It just takes time :-) mtn 
> automake need to stabilize...

Yeah, not really my problem, I have enough to keep me busy with core
stuff ;-).  But I'm sure the various people working on front-ends
would appreciate any suggestions on how to make them more useful and
usable.

"mtn automate" is pretty stable, with a few exceptions (well, one
exception, I think?) commands just get added to it, not changed or
removed.  Now, it could definitely stand to be more _complete_...
Though for pure browsing, it is only missing a few things (maybe
annotate, and a way to get a file-restricted history graph?).  The big
gaps are operations that modify the workspace or repo.

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey