On Sunday, August 4, 2002, at 09:42 AM, Jim Blandy wrote:
> I think people often avoid confronting interpersonal problems by
> imposing policies, or using technologies, that, on their face, don't
> single out anyone in particular, but, in effect, prevent or work
> around a particular individual's problems. But these policies often
> make life mildly more annoying for everyone.
I think this is the crux of the issue. The theme that seems to be
emerging in this discussion is that non-mergable file formats require
communication between the developers working on them. Locking schemes
pretty much boil down to a very low bandwidth channel - a single bit
that, in the best case, is interpreted as "Hey, I'm doing some work on
this file. If you need to change something here, talk to me and find out
what I'm up to first." The good thing about locks is that you get that
message *before* you go making unmergable modifications.
There are, of course, lots of tools for communication out there, and
it's really a question of project management to decide how communication
between developers is going to happen. I think the question we should be
considering is what, if anything, Subversion should do facilitate
communication.
Here's one idea that I'll toss out to Old Hundred Eyes for
consideration. Instead of advisory locks, why not just provide the
ability annotate files and directories. (Nothing to do with cvs
annotate, though the name could lead to confusion with svn blame).
The command would work on files or directories in a working copy:
svn annotate TARGET...
It would pop up an $EDITOR, similar to svn commit, and the user would
enter some sort of advisory - "Hey I'm working on issue XYZ, so if
you're working on anything that calls the Quux API, let me know." This
text would get associated with the targets given on the command line,
and stored in the repository. The other commands would have to be made
aware of annotations so that they could report their existence properly.
svn status -v could display the advisory text, while status (no option)
and update would just display a flag indicating the presence of the
annotation.
I think annotations should not be stored as a property, that is, adding
an annotation should not create a new revision. This would require an
extension to the FS, which I'll leave to the data modeling gurus to
figure out. There obviously needs to be a way to remove an annotation
once it becomes obsolete, and we may want to keep a history of
annotations, along with the dates they were active.
I'm not actually sure that 'svn annotate' is a good idea, but it does
have the advantage that it stores the metadata close to the data it's
self. If you check out a copy of the source tree without having read
your email, you at least see what files are annotated.
Thoughts?
Colin Putney
Whistler.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 4 23:44:29 2002