<< Why's it so tough to sink a basket? | Main | Hardwiring >>

Hooray for standard formats!

chris on 2007-Aug-14 09:57 AM

IDEA 7 has a nifty feature called 'Shelve changes'. Some SCM systems have this -- it's the ability to take a set of changes and have the SCM 'forget' about them so you can do other work independent of them. You can then reintegrate them back in one fell swoop. The typical use case is to move aside changes for a big feature to implement one or more small features at the same time so you don't accidentally bring the 'big feature' changes in with the small ones.

(From what I understand this is built-in to most distributed SCM systems -- branches aren't the heavyweight things they are in Perforce, so every feature becomes its own branch and has its own changesets associated with it. Cool.)

Anyway, somehow IDEA lost track of a shelf I'd made a week or two ago -- I hit Alt-9 to see the changes, then Alt-RightArrow twice to the see the 'Shelf' tab, only to see there was no 'Shelf' tab. Shit! I tried to remember everything I did, and while it wasn't a huge amount it was an hour of work plus testing.

Before I started on that path I went to the directory where IDEA stores all of my stuff: ~/.IntelliJIdea70. Under config/shelf was a single file with the extension of .patch and the name I'd given the shelf. Sure enough, the tried-and-true patch format sat there, and after choosing 'Version Control | Apply patch...' my changes were brought back in. Awesome!

It would have been really easy for the folks at Jetbrains to create their own format for shelved changes, and to tightly couple the 'reintegrate shelf' functionality with the file itself, disallowing its use anywhere else. That they didn't shows, again, how much they know how developers work. The fact that I also could have applied them with the command-line patch tool is also great, and another argument for sticking with standard formats where possible.

Comments

Distributed SCM makes live *so* much easier

Indeed, plentiful, nearly free branches and as many personal repositories (and working directories) as you want are common with distributed SCM systems. Once you "go" distributed, it's hard to suffer centralized systems.

I use Darcs, for example, and when I need to hack on an experimental change to The Big Project, I just create a new repo for hacking: "darcs put bigproject-experimental". That's it: a copy of the mainline repo now lives in the bigproject-experimental directory. In that directory, I can hack on experimental changes independently of my mainline work, accumulating changes and making commits into the independent repo. Later, if I decide the overall change is worth keeping, I can merge it into the mainline repo with a single command: "darcs push bigproject-main".

For teams, it gets even better. Each programmer can have his or her own copy of the mainline repo, in addition to creating as many personal branch repos as they want -- for hacking, for working remotely, for the laptop, and so on. Programmers can push and pull changes to and from each other's repos and from the central mainline repo (if there is one -- you don't actually need one). It's pretty slick.

Distributed SCMs are so much better to work with that, if I were forced to used a centralized system, I would actually use Darcs behind the scenes, synchronizing with the centralized system only when convenient.

Of the popular distributed SCMs, Darcs has the most flexible and powerful underlying model, but (for now) Git and Mercurial are probably better for large projects. (Darcs can choke on a couple of corner cases that, history shows, can occur on large team projects.)

Cheers, Tom

Posted by Tom Moertel on August 14, 2007 12:38 PM

I knew you'd chime in

As I was writing the parenthetical paragraph about distributed SCM, I thought: "Tom's gonna reply to this." :-)

For now, investigation on them is filed in the "Experiment after project release" folder, so hopefully sometime in November...

Posted by Chris on August 14, 2007 3:37 PM

New comments are disabled.

... implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
--Jon Postel, RFC 761

Archives
4/2008 (2) 3/2008 (2) 2/2008 (4) 1/2008 (3) 12/2007 (2) 11/2007 (8) 10/2007 (3) 9/2007 (2) 8/2007 (8) 7/2007 (5) 6/2007 (19) 5/2007 (4) 4/2007 (2) 2/2007 (4) 1/2007 (4) 12/2006 (8) 11/2006 (7) 10/2006 (11) 9/2006 (6) 8/2006 (2) 7/2006 (3) 6/2006 (14) 5/2006 (1) 4/2006 (5) 3/2006 (12) 2/2006 (14) 1/2006 (18) 12/2005 (12) 11/2005 (10) 10/2005 (9) 9/2005 (3) 8/2005 (6) 7/2005 (18) 6/2005 (12) 4/2005 (6) 3/2005 (21) 2/2005 (13) 1/2005 (12) 12/2004 (14) 11/2004 (23) 10/2004 (23) 9/2004 (22) 8/2004 (7) 7/2004 (12) 6/2004 (23) 5/2004 (29) 4/2004 (24) 3/2004 (34) 2/2004 (21) 1/2004 (31) 12/2003 (16) 11/2003 (37) 10/2003 (32) 9/2003 (24) 8/2003 (21) 7/2003 (29) 6/2003 (27) 5/2003 (27) 4/2003 (26) 3/2003 (41) 2/2003 (29) 1/2003 (38) 12/2002 (46) 11/2002 (41) 10/2002 (45) 9/2002 (99) 8/2002 (111) 7/2002 (7) 6/2002 (19) 5/2002 (18) 4/2002 (7) 3/2002 (8) 2/2002 (22) 1/2002 (13) 12/2001 (4) 11/2001 (5) 10/2001 (5) 9/2001 (6) 8/2001 (6) 7/2001 (5) 6/2001 (5) 5/2001 (4) 4/2001 (4) 3/2001 (3) 2/2001 (6) 1/2001 (3) 12/2000 (1) 11/2000 (2) 10/2000 (7) 9/2000 (7) 8/2000 (6) 7/2000 (13) 6/2000 (6) 5/2000 (2) 4/2000 (3) 3/2000 (8) 2/2000 (4) 1/2000 (4)

All Tags
ada advertising aging aimeeman airlines ajax alcohol animals annoyances ant apache api astronomy attention baby badsoftware barackobama beauty bicycle bicycling birthday biz blog blogging books brain broadband browser build bureaucracy california cars cartoons cats charity chores classifieds clothes clown codegeneration coffee collaboration comics commercials communication community conference config corporate cpan css curmudgeon cwinters.com daily life dancing database datetime dating dc death debate design development distributed diy documentation dormont doublespeak driving dumb ebay ecommerce econ education ejb ella email embedded environment etech exercise expat family farming feed fiber fiction food fun furniture future gambling games geek gentoo geology gis government grammar greece groups gui hair hardware harrypotter hate health hiring history holiday house http ide identity illness imap ipod isp j2me jamming java javascript javaspaces jini job journalism kickass kids kinesis language lazy links linux lisp list lists living mac madison management map marriage maven media medical memory messaging meta military money movies moving ms150 music naked niagara nostalgia nyc oi2 opensource orm outsourcing parenting patent patterns pennsylvania perforce perl personal photography photos pinball pittsburgh planning politics postgres postgresql presentation privacy programming proliant proxy pseudoscience purity quiz quote race radio rant refactoring reflection relationship releases religion rest reunion review ricksantorum rules sandiego scatological science scm scripting security serendipity server servlet sex shell silly slang sleep soa soccer solaris specialization speech sports spring standards starwars steelers struts suburbs swing sysadmin tags team technology telecommuting terrorism testing thnkpad tradition transaction transportation travel traveling tutoring ui unix uptime usability usergroup vacation vc vocollect voice voting vpn walmart washingtondc weather web webservices wedding wiki win32 work writing xml yapc zeroconf