• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• In reply to: Jonathan S. Shapiro

Reactions:

• You probably need some form of "don't commit unless the image being changed is such-and-such", aka the compare and swap model. Otherwise too many changes get lost. There is a trade-off here. This model favors the small change. I have seen a situation where a large change always failed because someone always checked in a small change while the person responsible for the large change adsorbed and re-tested the large change with the previous small changed incorporated. When this situation happened it was handled by social means. I.e. No checkins until the large one is checked in.
• CVS works a lot better if people don't have write access to its repository.
• I would forget about encrypted files for version 1. One reason is that this is (it is isn't it?) an open source project. Encrypted committed files seem inappropriate. Also probably most of the real requirements will be covered by an encrypted transport layer (e.g. IPSEC). Authentication is a different matter.
• As the proud owner of a 28.8 modem, I like the idea of sending compressed deltas. If I send you a delta and the SHA hash of the expected result of applying the delta, you can easily check the transfer.
• If I was doing the work, I would think long and hard about the something new vs. modify cvs choice. Working code is a wonderful thing. It always makes me nervous when someone says that a useful, well accepted tool is so broken it needs to be completely rethought from the beginning.

[ Next ]
• In reply to: Jonathan S. Shapiro