-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jun 13, 2008 at 06:58:12PM +0100, Philip Pemberton wrote:
> Robin D. Bussell wrote:
> > http://darcs.net
> > 
> > No gui client or anything but a wacky distributed nature, there's not
> > necessarily a need for a central "repository " as such.
> 
> Have you seen Mercurial?
> 
> http://www.selenic.com/mercurial/
> 
> Pretty much the same concept, but without the exponential commit time, or the 
> weirdness of Darcs (or at least /I/ found Darcs a bit weird).

Or for that matter, Git. It's fast, really, really fast, and written by
Linus Torvalds specificly to manage the Linux kernel, one of the largest
open source software projects out there. It seems to be gaining
mindshare very quickly, with git-hosting sites like github, gitorious
and a bunch of others available to host your git-using projects. It also
has an interesting, and IMO useful, workflow where rewriting history is
actually encouraged. For instance if I'm working all day long on a
module, making changes here and there, I can run:

git rebase -i f8d45932269b66c6ff48b312cc2b505fc43f439a

and change the order, descriptions and content of every change since
that revision. The advantage being when you push to the master
repository your change history isn't cluttered up with random junk until
the end of time.

Similarly you can avoid merges by rebasing onto the current head of some
branch, again to keep the history consistant.

There are even ways to commit a sub-set of changes. If I find a one-line
fix somewhere, I can commit just that fix with git add -i somefile; git
commit Or I could stash my current changes with git stash, do something
else, and then do git stash apply to go back.

I'm a former Monotone user myself, and am switching everything over to
git now. For my art projects I've got an experimental workflow I'm
trying out using the git submodules feature. Take the example of my
Meter Clocks. My repositories for it are as follows:

meter-clock:

firm/ -> meter-clock.firm
hard/ -> meter-clock.hard

meter-clock.hard:

elec/schem -> meter-clock.schem

In "english" my schematic, not the pcb layout, just the schematic, is
stored in meter-clock.schem This is shared with all the different
versions of the hardware, panel meters come in tonnes of sizes, but the
electronics are all the same, so hardware designs go in meter-clock.hard

Now that said a specific instance of a meter clock will consist of a
hardware design, and a firmware design, so the top-level repository then
has a specific version of the firmware and a specific version of the
hardware assigned to it. In summary the advantage being one firmware
version could potentially work on all sorts of hardware, equally, one
version of hardware could work on all sorts of firmware, so they stay
seperate. What went into a particular instance, as in an actual,
physical meter clock, is then traceable to the various revisions and
branches of those main repositories.

Finally, say I write a nice bill of materials generator for my pcb
layout. I can add *that* as a sub-module to something appropriate and
in effect use the sub-module system to keep track of what version of my
bill of materials generator happens to work properly, and update it as
needed.


That said, submodule support is fairly untested as far as I can tell, so
I may wind up fixing bugs eventually, I haven't actually built anything
with this new system, yet. I'll know in another month or two.

- -- 
http://petertodd.org 'peter'[:-1]@petertodd.org 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIUwAb3bMhDbI9xWQRArv2AJ4+sLDFxLzXVddUBl68OXuJ7jrSFQCaA0rY
TGochGQGUna0scLAarIxiR4=
=3ll0
-----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