monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] short-lived working directory branches


From: Vladimir Vukicevic
Subject: [Monotone-devel] short-lived working directory branches
Date: Thu, 23 Jun 2005 01:29:41 -0700

I started mumbling about this on irc a few days ago, and figured I
ought to write down the idea and see if it makes sense to others.  The
problem is essentially this:

I have a large working set (300mb or so on-disk).  I work on numerous
independent bugs/issues within one working directory, usually
organized by one main feature/goal/project.  Usually, the issues all
involve different files, so I can easily keep them separate for
purposes of posting patches for review and in general changing the
code.  However, on occasion, I have multiple issues that all need to
be fixed in one file.  As my usual development cycle is 1. make patch;
2. post patch for review; 3. incorporate review comments and go back
to #1, if there are any; 4. commit patch.  There's a delay between 2
and 3 -- which means that working on a separate issue, but in the same
file, becomes difficult, because the patches start to mingle.

Having a separate branch isn't a solution; the branch itself is cheap,
but it requires an entirely separate working directory, and more
importantly, an entirely separate build.  ccache can help, but even
then we're talking about a 1gb objdir, 300mb srcdir, and ~15 min of
build/ccache time, just to track independent changes to one file!

My suggestion is to create some tools to let you deal with small,
short-lived working directory branches. You could pick a file or one
set of files and save them away with some tag name; a 'switch' command
would switch a set of files to either another minibranch, or to the
current heads of those files of the real monotone branch your WD is
in.  This would let you make changes to file F for feature A, save F
as a minibranch named feature-A, then switch F back to the real branch
head (before the changes for A) and do some work for feature B, save F
as a minibranch named feature-B, then switch back to feature-A for
continuing feature-A work, and so on.

My initial thinking is that I can implement all of this with some
shell (or perl, more likely) scripts, storing data inside the MT/
directory in each working dir.  I would make these minibranches
entirely manual; once you commit one minibranch (just by switching to
it and committing), you'd manually have to switch to the other
minibranches and merge.  However, I'm wondering if these types of
features would be useful to have in monotone proper, with maybe a
little more support -- e.g. once you commit a minibranch, have that
commit be merged to all other minibranches that involve the changed
files.  Does this type of process seem useful to anyone else?  Or can
anyone suggest a better solution to the problem?

     - Vlad




reply via email to

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