monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: Google Summer of Code 2006


From: Bruce Stephens
Subject: [Monotone-devel] Re: Google Summer of Code 2006
Date: Fri, 21 Apr 2006 11:51:42 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Nathaniel Smith <address@hidden> writes:

[...]

> I've been wondering vaguely whether there would be some way to make
> this work, and maybe also provide a smoother ramp-up to people just
> starting to use monotone.  There's more overhead in starting up with
> monotone than other systems, because you have to make a branch name
> and everything (and maybe this will even get worse when we add
> policy branches).  There's a real payoff for this, but you pay the
> cost up front and get the benefits later.  Maybe it would be better
> to have some sort of "anonymous branches" mode that acted more like
> other systems's location-based branches, that one could start out
> with, and promote to the real branch model later?  And say that you
> can do quilt-y stuff with anonymous branches only, so as to have a
> clear demarcation between revisions that can change and revisions
> that can't?

Maybe.  I'm not so sure that inventing branch names is such a
pain---it's more that you know they're always going to be visible.  

So maybe hidden branches come in here, along with (presumably) the
policy stuff, which I guess could say that some branch names should be
hidden, and maybe suggest some kind of rule for new temporary ones?

So if I'm working on net.venge.monotone, maybe it should be easy for
me to say I want to commit some new revision to do with "commands.cc
splitting", and the policy covering net.venge.monotone can come up
with some kind of branch name suitable for that, which would normally
be hidden to other people?

That might help with reviewing, and quite probably other kinds of
workflow.  If I can easily commit to branches that don't get in
anyone's way, then they become attractive for smaller bits of work,
and I can point people at them for review.


Hard to know whether there's a suitable coding project there, though.
I have a suspicion that someone might look at the issues for a month
and decide that a suitable technical solution is "monotone diff > ++;
monotone revert .", together with emailing diffs for review.  Probably
that isn't the kind of work Google is looking for.




reply via email to

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