[Top][All Lists]
[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.
Message not available
- Message not available
- Re: [Monotone-devel] Google Summer of Code 2006, Ingo Maindorfer, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Richard Li, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Thomas Keller, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Richard Li, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Chad Walstrom, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Richard Levitte - VMS Whacker, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Ethan Blanton, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Richard Levitte - VMS Whacker, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Ethan Blanton, 2006/04/21
- Re: [Monotone-devel] Google Summer of Code 2006, Richard Levitte - VMS Whacker, 2006/04/21