Re: [tlug] search for encrypted information exchange

[Curt Sampson <cjs@example.com>]

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.

> 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.

>  > Merging is a bit of a pain: you need to throw away the conflicting
>  > version, load up the two versions that conflict, manually merge the two,
>  > and then commit the new merged version. Good communication is essential,
>  > lest another commit create a further conflict whilst you're doing this.
> 
> 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.)

> BTW, git allows you to specify a custom merge tool, which I would
> guess would allow you to specify a script that gets the three versions
> of the file (local, to-merge, common ancestor), decrypts them, then
> invokes your favorite merge tool on them, and finally encrypts.

Yeah, but does your favourite merge too be careful never to write any
temporary files containing any of that data?

> Of course this could get very hairy if multiple encryption keys or
> signatures are involved.

Actually, that's not hairy at all. Just always encrypt to the ones to
whom the two versions shared in common, and chose from the others.
Signatures on the incoming versions are merely checked; you sign the
outgoing version yourself.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com