Edward Harvey writes:
> I am not trying to implement any change that would guarantee never a
> merge. That has already been done with needs-lock. But the downside of
> needs-lock is serialization of developers' work, prohibiting them from
> working in parallel, even though most merges are easy and/or automatic.
So, if I understand you correctly, this discussion is to solve the,
presumably rare, situation when you're doing a change that will be
hard to merge with other changes in a file that's normally perfectly
mergable. Correct?
> I am only trying to communicate the presence of a lock to users who
> don't own the lock. Because sometimes a person is going to make
> extensive changes to a file, which he/she knows will be difficult or
> impossible to merge. So the user obtains a lock, indicating that it's
> unwise for anyone else to work on it until after the next commit.
Yes, this is one use-case of locking files without having
svn:needs-lock set. But, as others have pointed out, this
communication could be done using automatic eamils (or some other
notification mechanism) triggered by a post-lock hook script. It
could be set up to only notify when svn:needs-lock is not set,
avoiding unnecesary traffic. The lock would still protect the one who
*does* the unmergable change from others working on the file. If
others ignore the (rare) notification, they pay the cost for doing so.
...
> That's right. Some servers face the internet with a limited data pipe,
> using strong encryption and authentication is a network cost. Those
> administrators would not want their users to constantly poll for
> updates.
>
> But some servers are internal, at software companies, running a
> lightweight protocol such as svnserve. And these can handle excessive
> polling with no trouble at all.
Maybe, but it is still lots of overhead for something that's rarely
needed. But this is a question of local policy that we can't decide here.
> The idea of automatic polling is not for everyone, just the ones who
> want it.
>
> > Well, sort of - since needs-lock actually does affect your
> > local work as it would need to somehow signal you not to make
> > changes (set R-O on the file) and you may already be making
> > the changes.
>
> Good point. But I think that's acceptable behavior. Bear in mind, the
> whole read-only bit would be a feature that's disabled by default. So
> you would only experience this behavior if you intentionally turned it
> on.
>
This last part is why I would be pretty resistant to accepting such a
change. You're pushing for an optional feature that will be rarely
needed (=used) and that could be achieved with out-of-band
communication that could be automated quite ellegantly (IMO) in the
current framework. We certainly have optional features in subversion
today, and we could add more in the future, but the problem is that
they tend to be heavily undertested. I have no concrete example, but
I would be surprised if use-commit-times hasn't some bugs just waiting
to be uncovered just because it is seldom used and that it is hardly
covered at all in the test suite. (I may well have introduced
something during refactoring in the 1.4 process.) So, in short, I
think this idea doesn't pass the cost/benefit ratio test...
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 3 09:48:38 2006