On 8/2/07, Dennis Byrne <dennisbyrne@apache.org> wrote:
> Hello Ben,
>
> > everyone's working copy, and only becomes read-write when you 'svn
> > lock' it. Thus, you discover pre-existing locks *before* you even
> > begin to edit the file.
> 'svn:needs-lock' property on a file, then it becomes read-only in
>
> I wasn't aware of this. I know this is a question more appropriate for the
> user list, but you are saying the svn server keeps track of who has locked
> what?
Sure, how else could the server enforce the lock, if it isn't tracking
locks? :-)
Read the section about 'locking' in the online svnbook for a complete
explanation of how the system works. It's very similar to what you're
already proposing. (Though, we only recommend it for files that
*must* be edited serially, like big binary formats, which can't be
merged together.)
>
> > Regarding your conflict-server idea: perforce solves the problem by
> > keeping *all* working copy files as read-only. You need to 'p4 edit'
> > a file to make it read-write, at which point the server then keeps
> > track of exactly which files you're editing. You can ask the server
> > (at any point) who is working on a file.
>
> In a similar vein, is there demand from the user community to know when a
> file is stale once the user begins to edit it? In other words, I think it
> would be nice to notify a dev if they are not working with the latest
> revision. Currently Conflict does not do this, but is in a realistic
> position to do
I'm not sure if there's demand for your feature. Certainly, we've had
12+ years of CVS and Subversion lacking this feature, and I've never
heard of anyone asking for it.
The feature seems to be motivated by a deep desire to avoid
out-of-dateness (and conflicts) at all costs; but this sort of goes
against the whole philosophy of the copy-modify-merge model. So what
if two people edit the same file at once? You merge, and deal with
conflicts. If conflicts are happening on a daily basis, then the team
is somehow failing to communicate effectively; it's a problem best
solved socially, rather than via a central database trying to
technologically make people aware of each other's actions.
Furthermore, the whole open source world has lately been moving toward
decentralized version control systems, which is even *more*
loosey-goosey in terms of people working simultaneously on the same
files. These systems don't just eschew merges and conflicts, they're
entirely *built* around the assumption of frequent merging. As these
systems get more popular, it seems like an argument (in my mind) that
there's less and less demand to solve the problem you're trying to
address!
I don't want to dissuade you from working on scratching an itch you
think is interesting, but I thought you might at least want to hear
some arguments as to why the itch may not be very relevant to most
users. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 2 23:31:31 2007