I'm heading out of town in a few minutes - but this is blasphemous and 
interesting!  :)  I will ponder while traveling and maybe give your repo 
a look when I return.

Peter Todd wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, Aug 24, 2007 at 09:39:09PM -0400, Timothy J. Weber wrote:
>> I don't think I totally get it, but thanks for the description; it's 
>> definitely an interesting idea and I'll put it on the "to explore" list.
>>
>> I think it may be a significant difference that I spend at least as much 
>> time with projects that have well over 100,000 lines of code as with 
>> ones that are a few files and run on an 8 KB chip.  In that milieu, 
>> creating a new project is something that happens rarely, but sharing a 
>> piece of code with another person is common - so I think that may be 
>> better suited to conventional refactoring into documented modules with 
>> clean interfaces than to reuse by branching.  But maybe that's because I 
>> haven't seen what you're doing!
> 
> Well, you can always get yourself a copy of monotone, and grab a copy of
> my publically available monotone repository... :)
> 
> Bear in mind I'm still working on how to best make use of my setup... I
> think the key idea is that if merging is really easy, branches can
> become a "feature", rtc chip, debugging, rather than a "version" or
> "type", ie, stable, devel.
> 
> Documented modules are all nice and well, but it's quite tough to have
> one of those documented modules be "the build system" But if one of the
> "feature" branches is "the build system" then keeping it up to date, and
> merging it into project branches becomes possible.
> 
> Now my idea of uses branches instead of software libraries is pretty
> uncommon, if not completely new. And there are some problems with it in
> terms of day-to-day usability. However from what I can see the branches
> as features concept is used a lot in big projects useing good revision
> control. Monotone development itself has dozens of branches for various
> experimental, and not so experimental, features.  More importantly, if
> someone is working on supporting foo, they can get initial support for
> foo done, merge it into the mainline, and they continue working on foo
> some more. Merges can go both ways, to update foo from the mainline, and
> the mainline from foo, and this process can go on indefinetely. Foo
> could be a really small feature too, but the process is easy enough that
> it's still doable.
> 
> Also importantly, why does it have to merge into the mainline? It's
> quite possible for changes to foo to be merged into the bar feature
> which in turn is merged into someone's specialty, "customer custom 1.5b
> firmware fixes" Now say along the line foo is also merged into the
> mainline. Well when mainline changes are propegated into that custom
> 1.5b firmware fixes, on Monotone nothing bad happens. CVS can't even
> *begin* to do that, let alone do it without getting very confused as to
> why changes are being applied twice.
> 
> - -- 
> http://petertodd.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFG0Kqx3bMhDbI9xWQRAsPeAJ9JjIq1FhRYoIBtoTpGZRkTurlQkACgj4v7
> PIoBKnpMYt1sfAnS5V783kc=
> =GYsU
> -----END PGP SIGNATURE-----

-- 
Timothy J. Weber
http://timothyweber.org
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist