[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Files changed on svn update

From: Neil Gunton <neil_at_nilspace.com>
Date: 2004-09-02 15:18:55 CEST

Ben Collins-Sussman wrote:
> > That's an idea, it would certainly be a workaround. I guess I was just
> > raising this as a possibly small thing for the svn developers that could
> > be fixed if it turned out that it was trivial or a small programming
> > oversight.
>
> It's not a trivial thing, nor an oversight. When you run 'svn up' at
> the root of your working copy, every single object in your tree must
> have its working revision "bumped" up to HEAD, even if the object didn't
> change. That's why every single .svn/entries file gets edited. The
> .svn/tmp directories change because that's where new repository files
> are constructed, before they're merged/copied into the visible working
> area.

Actually, this is still bugging me. I realize that .svn/entries needs to
be changed if the project files are actually updated during a 'svn
update' operation, but I was talking about the case where nothing needs
to be updated. I have checked, and when the files are already up-to-date
(i.e. at HEAD) then .svn/entries does not change, yet its modification
time is still changed. Unless svn is actually using file modification
time of .svn/entries as part of its functionality for determining
versions, I think that changing the modification time of a file that
hasn't actually changed at all is unnecessary.

If the file modification time of .svn/entries is actually being used
then I guess that would explain it, but otherwise it seems like a simple
programming error - perhaps the file is being opened for write before
svn knows that no changes will be made? This could be fixed by simply
opening the file a little later in the process, once we know that
changes will actually be made. But, as I said, if the mod time is
actually used then I'll just shut up!

One more (small) point... why have a separate tmp directory in every
.svn subdir, rather than just one central temp directory for subversion
to use for all projects? It seems like a needless proliferation of
subdirectories, since there can be a lot of them in any project. I know
that when I put my web development projects under subversion it suddenly
took about twice as long to traverse the directory tree during searches,
because the number of subdirs had increased so much. Of course I can do
all kinds of workarounds for the various tools I use in order to make
them ignore .svn, and again this is just a small niggle for an excellent
tool. But wouldn't it have been better to just have one temp directory
for subversion rather than a distinct one for each subdir? It's fairly
trivial to ensure against filename collisions. This is really a small
point, but just raising it for the sake of discussion.

Thanks,

-Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 2 15:19:19 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.