From mboxrd@z Thu Jan 1 00:00:00 1970 From: jas@corpus-callosum.com (Jeff Sickel) Date: Fri, 25 Mar 2011 16:00:37 -0500 Subject: [9fans] drawterm bug In-Reply-To: <201103252109.18156.dexen.devries@gmail.com> References: <6a7e42f7236652d4761e22c1159e92db@ladd.quanstro.net> <1301082530.30065.1433892565@webmail.messagingengine.com> <201103252109.18156.dexen.devries@gmail.com> Message-ID: Topicbox-Message-UUID: c16660fc-ead6-11e9-9d60-3106f5b1d025 On Mar 25, 2011, at 3:09 PM, dexen deVries wrote: > On Friday 25 of March 2011 20:48:50 Ethan Grammatikidis wrote: >> What on Earth is a quilted patch queue? I always thought the whole point >> of using a drcs was that you could work in your own branch. I've only >> used a drcs once, but everyone had their own branch there & it went >> pretty smoothly. It's a made up reference to the mq extension (search for 'quilt'): http://mercurial.selenic.com/wiki/MqExtension > I believe branches in hg are somewhat permanent. Your branches have direct, > one-to-one, relationship with remote ones. Also, you can't exactly remove a > branch in it, AFAIK. But there is `Local Branch Extension' available. Hg branching is very different than the use of the queues extension. I've had decent success using hg branches in the past, much safer and easier to manage than queues. > after using hg for some time, i went for git where branches are more > ephemeral. no idea why this group shuns git, but i'm in no position to > proselytise. > > perhaps porting fossil (the dvcs) [1] to plan 9 would be a good option? Personally I went the hg route instead of git for a few reasons: - it was easier to build Python and install Hg on the targets I needed than to build/install most of the other options at the time. - at the time getting git to run on anything but a few distros of gnu/linux was more effort for less bang, if not ending up in a fizzle. It's easier now that the coding monkeys have taken on the task of releasing git into the wild. - the alignment with tools I'd used in the past fit well. Hg branching and merging work a lot like devman (another tool killed by sun(tm), and some other tools I've used. It's not the only dvcs out there, but it's got good backing and runs everywhere python is available (which is more than the current git targets). Though I'd like to rely on venti, it's not really a source control system. Metadata about a change can be important if managed well, especially in large groups. There has been discussion on this list about trying to come up with a more Plan 9-influenced source revision system. -jas