[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [Issue 533] New - implement reserved checkouts

From: Fox, Peter <peter.fox_at_convergys.com>
Date: 2002-08-05 18:15:44 CEST

Software developers do occasionally have binary files that cannot be merged.

Delphi 4 has resource files that are stored in a binary format.

A number of modelling and GUI builder tools have binary format files.

Generally these are propriety tools that may not have any mechanism for
converting the file to text. They generally don't have specialist merge
tools associated with them. As such you need to lock the file since you
cannot do parallel development and merge the results.

Often you want to store image files, for example GIFs. Again no merge tools


-----Original Message-----
From: Jim Blandy [mailto:jimb@red-bean.com]
Sent: 05 August 2002 17:04
To: Greg Stein
Cc: dev@subversion.tigris.org
Subject: Re: [Issue 533] New - implement reserved checkouts

Greg Stein <gstein@lyra.org> writes:
> Oh, geez. This whole thread is way too narrowly scoped. *Everybody* is
> talking about developers and source code. Fine, geez. No locks.

No, no, no. I just figured your point stood, that it was obvious that
locks can be useful for unmergeable file formats, and didn't mention
it further. (I had a sentence like, "This doesn't address Greg's
concerns about unmergeable file formats" in an earlier draft of my
letter, but I left it out for some reason.)

The question I wanted to ask is, are locks useful to software
developers, too? They're often used in that context; is that always
an abuse of technology, or are there situations where it's a good
solution? What makes it a good solution in those cases?

If you want to design behavior that's useful in both contexts, then
you need to ask both questions, right?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

NOTICE:  The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential.  If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 18:17:01 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.