Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Nathaniel Smith <njs <at> pobox.com>
Subject: Re: Re: Google Summer of Code 2006
Newsgroups: gmane.comp.version-control.monotone.devel
Date: Thursday 20th April 2006 22:33:59 UTC (over 11 years ago)
On Thu, Apr 20, 2006 at 12:05:25PM -0500, Chad Walstrom wrote:
> Bruce Stephens   wrote:
> > For big workspaces, it would be nice to put existing changes on to a
> > "shelf", do the bugfix, then take the changes off the shelf and
> > continue.  (GNU Arch provides this: IIRC, "tla undo" saves patches
> > into a ++ type directory, and "tla redo" reapplies them.)
> 
> Not that I'm being helpful here, I currently just do a 
> 	monotone diff > ++patchname; monotone revert
> 	
> Make the changes, then run patch on ++patchname to reapply.  Not as
> slick as quilt/shelf functionality, obviously.  I believe mercurial
> added an 'mg' command to do this type of thing.  Neat stuff.

"mq".

The tricky part about real quilt-style functionality is that it
involves mutating the revision graph.  That works fine if you make
sure that the revisions you use it on only ever exist in a single
repo.  There's some immediate tension there, though, since one of the
core parts of monotone's philosophy is to eliminate the idea of "this
repo, the one right here on my disk" as an important thing.  It also
causes simple usability problems -- the quilt systems for hg and git
don't (AFAIK) provide any particular way to distinguish between
quilt-managed, mutable revisions and real, immutable, distributable
revisions.  You just sort of have to be careful what you sync.

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?

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
 
CD: 3ms