> > If the svn:needs-lock property is set, then the file should be read-
> > only. Did your editing tools not notice this?
Yup - absolutely. The editting tools specifically reminded me that it was a
read-only file. However, I'm talking about the situation whereby we
intentionally "hack" a file, with absolutely no intention of keeping the
hack whatsoever, or commiting it to the repository.
An example is a file we have which contains the maximum amount of memory we
can use. Occasionally as part of testing code we're in the habit of just
hacking the file containing the magic number, but we would never want that
to be committed to the repository.
> > The point of the read-only-ness is to remind you, "hey, you should
> > lock this thing before starting work on it."
Sort of. As an extension to this though, use our antiquated DOS-based RCS
system ensures that if you have no lock on a file, you're not editting it no
matter what your working copy thinks ;-)
To be completely fair I think subversion's pre-commit hook will do the trick
admirably, with the added bonus of ensuring we never forget we've got files
"hacked" as well - a win/win situation :-)
> > Granted, some tools will flat-out ignore the read-only-ness. So as
> > Peter said, you could install a pre-commit hook which *demands*
> > that any incoming file with a svn:needs-lock property be already
> > locked. But IMO, that's a bit too late, the damage is already
> > done. Even if the hook prevents such a commit, you've already
> > (potentially) wasted your time creating unmergeable changes,
> > right? Somebody could have already committed a newer version of
> > the file while you were working, and now you've got an unmergeable
> > set of conflicts.
Absolutely - however we're talking about the situation where we know we're
screw ourselves over - but using an atomic commit if/when we swap to
subversion we could be doing a lot more damage :-(
Cheers for all your help - been very very useful indeed!
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 16 17:12:24 2005