Re: [tlug] search for encrypted information exchange

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2009-08-25 01:03 +0900 (Tue), Stephen J. Turnbull wrote:
 > 
 > > What makes you think git would cause more conflicts than Subversion?
 > 
 > Subversion is centralized, so when you update you *know* you have the
 > most recent commit. Git can let patches float around all over the place
 > if the group doesn't have a reasonable amount of discpline.

Thanks you for playing.  No, that's not how it works.  svn commit is
equivalent to git push, requiring equal amounts of discipline.  The
difference is that the git user probably has a local copy recorded in
her branch, while the Subversion user has to remember to branch.

 > > In fact, git might be preferable to Subversion on the grounds that if
 > > there *is* a conflict, git guarantees that you have literal copies of
 > > all the files involved in the conflict.  (Maybe Subversion does too...
 > 
 > Yes, it does.

AFAICS from your reply to Edward, it seems likely that you can
generate them by reverting patches, but in git you actually have
snapshots you can just check out.  Again, the git UI encourages more
robust, more secure practice.

 > > That's stupid. :-)  Just use a dVCS like git or Mercurial.  It's true
 > > that one can run into further conflicts, but the urgency is much less
 > > since one can just stay on one's branch until one feels like merging.
 > 
 > You can do that in Subversion, too, merely by taking your own copy
 > over the repo copy. But you really want to merge this sort of stuff as
 > quickly as possible, since it's usually done by hand. (If you use tools,
 > you usually end up putting plaintext on disk.)

Do this work in a VM that doesn't have any physical disks mounted, and
gets the originals via a non-file-system network protocol.  That's
proof of concept, there are lots of other ways.