-----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-----
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist