Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

From: Theodore Tso <tytso@mit.edu>
Date: Jul 31, 2008, 21:22 UTC
Message-ID: <20080731212215.GI20819@mit.edu>
In-Reply-To: <BLU0-SMTP273E4683B41DB7E44122F0AE7C0@phx.gbl>

On Thu, Jul 31, 2008 at 04:57:24PM -0400, Sean Estabrooks wrote:

Show 13 quoted lines

> > We find ourselves constantly having to shift gears and work on other
> > things in the middle of whatever it is we're currently working on.  For
> > instance, in the scenario above, A might be branch that contains a
> > feature going into our next release.  B might be a bugfix and takes
> > priority over A, so you have to leave A as-is and start work on B.  When
> > I come back to work on A, I have to rebuild A to continue working, and
> > that's just too expensive for us.  So we use the monotone-like
> > new-workdir which allows us to save those build artifacts.
>
> A decent build system will only compile the source files that actually
> changed when switching branches.  Couple that with a compiler cache
> (such as ccache) and switching between branches in the kernel or git
> project usually isn't prohibitively time consuming.

That being said, if the bugfix is on a "maint" branch, and one of the things that has changed is a header file that forces most of the project to be recompiled, a separate work directory may be more convenient. Of course, a separate work directory (whether created using "git clone -s" or "git-new-workdir" means more disk space and it means greater use of the page cache or a slowdown while the different sets of sources get paged in and out. Of course, you could hack git-work-dir to use cp -rl to initially copy the working directory using hard links, and then when the new branch is checked out, if most of the files haven't changed, the files in the working directory could be shared too. A lot depends on how much you want to squeeze the last bit of hard drive and speed optimization, and how big your project is.

       	    	      	    		      - Ted