James G. Sack (jim) wrote:
Cheap branching with cheap remerge is a hallmark of the distributed
source control systems.
Well svn branching is quite cheap. But merging is a potential headache.
Is merging really easy on distributed systems? Seems like there must be
some powerful magic involved, eh?
Yes, there is. In fact, it is sufficiently powerful magic that it is NP
and can effectively put some of the systems (like darcs) into an
infinite loop if you have too many interlocked branch-remerge loops.
Fortunately, by the time something gets sufficiently complex to grind
darcs to a halt, it has probably also ground the developers to a halt
due to complexity and confusion.
Generally, if I'm dealing with developers, I physically remove the hard
drive from their system once or twice a year. I generally give them a
week warning. I then pull that drive and put the drive into an IT
machine with a network mount for 2 weeks. The data they need doesn't
disappear, but it sure does annoy them for a day or two. After that two
weeks, the drive gets pulled and placed in off-site storage.
After 2 or 3 cycles of this, the developers understand their
dependencies *really* well.
An interesting way to provide for organizational policy without being
too draconian. Did you invent that? Seems pretty neat to me.
Sorta, it has been an incremental process. I used to just reimage the
hard drives out and let them whine. I'm getting soft in my old age.
The big problem is that developers often *do* need control over their
machines. So, you don't want to completely cut them off. However,
developers also tend to abuse the privilege, so you need some way to
pull them back to reality every now and then.
With drives having gotten cheap and SATA hot swap a reality, pulling a
drive isn't the pain that it used to be. Using the drives as backup is
generally the most cost-effective backup system for small companies anyhow.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
