Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] search for encrypted information exchange
- Date: Tue, 25 Aug 2009 18:30:25 +0900
- From: Curt Sampson <cjs@example.com>
- Subject: Re: [tlug] search for encrypted information exchange
- References: <20090824125805.GA1466@example.com> <20090824144551.GB5304@example.com> <87bpm52o8p.fsf@example.com> <20090824174339.GC16661@example.com> <87zl9o1cyh.fsf@example.com>
- User-agent: Mutt/1.5.18 (2008-05-17)
On 2009-08-25 18:04 +0900 (Tue), Stephen J. Turnbull wrote: > svn commit is equivalent to git push, requiring equal amounts of > discipline. Bzzt! Thank you for playing. The git process has more steps that need to be performed manually, (commit, pull, push vs. just commit), more states (locally modified, locally committed, remotely committed vs. locally modified and committed), needs several different ways of checking those states (there's no "svn status" to tell you what you have that the rest of the world doesn't), and many more opportunities for silent errors (such as pushing to the wrong repo). >From your statement, I'd almost thing you hadn't used subversion. Subversion certainly requires much less discipline than git when you want to stay in very close co-ordination with other committers on a branch, simply because you all actually *are* on the same branch, whereas with git you're always forced to work on a separate branch from everyone else. (Note I'm not saying that git doesn't have advantages in other situations, or even other advantages in situations like this, if you have the discipline. But keep in mind, I'm a pretty darn disciplined guy myself who tends towards and uses a lot of low-ceremony methodology, and I'm balking a bit at this.) > 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. To restate: the whole point is that you really don't want separate branches happening when the VCS can never merge for you. > Again, the git UI encourages more robust, more secure practice. In this case, not, I think; given the situation, files will always completely conflict, and thus subversion will always leave you with copies of both files, so that's not an issue. What is important is that you work very hard to minimize the number of conflicts and, when they happen, ensure that they happen as soon as possible. > > (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. Yes, I can think of dozens of ways to spend dozens of hours setting up more things to help get me out of complex situations of my own creation. That doesn't mean I actually want to spend the time doing that, rather than, say, working on something that generates revenue. cjs -- Curt Sampson <cjs@example.com> +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com
- Follow-Ups:
- Re: [tlug] search for encrypted information exchange
- From: Stephen J. Turnbull
- References:
- [tlug] search for encrypted information exchange
- From: Christian Horn
- Re: [tlug] search for encrypted information exchange
- From: Curt Sampson
- Re: [tlug] search for encrypted information exchange
- From: Stephen J. Turnbull
- Re: [tlug] search for encrypted information exchange
- From: Curt Sampson
- Re: [tlug] search for encrypted information exchange
- From: Stephen J. Turnbull
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] [tlug-admin] Call for presenters - September 12th technical meeting
- Next by Date: Re: [tlug] Unix's 40th Birthday
- Previous by thread: Re: [tlug] search for encrypted information exchange
- Next by thread: Re: [tlug] search for encrypted information exchange
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links