Hi,
On Monday 17 January 2005 00:06, you wrote:
> On Sun, 2005-01-16 at 17:29, Joerg Hessdoerfer wrote:
> > Ok. But why does it work on Linux, then? Your point is somewhat valid,
> > but there's code in SVN that should unprotect the files first, no? And
> > that should either work on all platforms or it's a bug...
>
> On Linux (and other Unix-like systems), not having write permission on a
> file means you can't change it, but you can still delete it or replace
> it if you have appropriate permissions on the directory. Since
> Subversion updates files by replacing them, we don't notice the lack of
> write permission.
>
> On Windows, the read-only bit means you can't change it, delete it, or
> replace it.
>
> > Besides, some proprietary development environments (we use one) use the
> > read-only flag to notify them that file contents where not changed by the
> > user. So they are set on all locally unmodified files, which SVN would
> > probably want to update. On Linux, this works fine, on Windows not ;-(
>
> I can understand the practical frustration here, but your proprietary
> development environment is essentially saying "no other tools should
> modify this file." Subversion could be modified to ignore the read-only
> bit, and it might not be a terrible idea (we know the file is under
> version control, so we sorta own it, so it might be okay to override the
> read-only bit on it; also, it would probably be a one-line change), but
> it's not really worth a ?!? in the subject line that we don't do that.
> Would you complain that your editor won't edit the file like you want
> to, that a perl script won't modify the files like you want to, and so
> forth? Just what do you expect the read-only bit to do?
OK, that's a valid reason. I just wasn't aware of the different semantics of
this flag (I mostly develop under *nix, so I didn't iterate too deep into
this).
The problem is, that this ~15.000 files in our working copy, and the tools we
use to work around this problem take quite a long time, so each update is
really painful. I was of the impression that the different behavior was a
deficiency in SVN, but I obviously was wrong.
The question is, would it be possible to have a sort of 'hooks' inside the svn
client code (libsvn_wc, ...)? This way, such things which are relevant for
some dev environs and not for others could be done by add-on tools. The point
in this would be, that you don't need to modify the client tools themselves,
but all would act alike.
We have written our own tool, specialized for our dev env, but some developers
prefer TortoiseSVN (they have valid reasons), and some the commandline, but
both don't integrate too well into our scenario (read: cause problems, due to
R/O issues) and our tool is too slow, 'cause it can't anticipate SVNs
behavior (it would take too long to do so, an 'svn -uv st' takes about
1.5-3mins on said repository).
I would really love to see something like hooks here, maybe as dynamic loaded
lib functions? Ideally, they would be called before and after update or
commit on any file, with some standard args (file path, repo and local
rev,...). Am I on dope, or this idea worth consideration?
Btw., we really love SVN, it has already saved us some hours or days worth of
figuring out what went wrong to the code base, and it's rock solid even for
our bigger products (15.000 files, 750 MBytes source code which are binary
files).
Thanks,
Joerg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 17 09:43:03 2005