On Thu, 2004-09-02 at 08:18, Neil Gunton wrote:
> 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.
[I'm moving this to the dev@ list, since now you're discussing design
and implementation details. Please followup to dev@ frome here out.]
You're saying that an .svn/entries file's timestamp is touched even when
the *entire* directory is already at HEAD? I wonder if that's just part
of our locking code. When libsvn_wc's update process "opens" a working
copy dir, it 'locks' it and reads the entries file into memory, possibly
tweaking stuff. When the directory is closed, the entries file is
written back to disk and the lockfile removed. I wonder if this code is
being overzealous and writing the entries file unconditionally?
>
> 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!
I'll let other WC folks answer that question.
>
> 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.
The idea is that any subdir of a working copy is a complete, standalone
working copy. You can break it off, and it will survive alone without
problem.
libsvn_wc creates all sorts of tmpfiles, writes journals to manipulate
them, then executes those journals. It's possible to interrupt a
complex Wc operation, leaving a directory in an inconsistent state;
that's why we have 'svn cleanup', which finishes executing the journal
and completes the work.
Put these two ideas together, and you have a new axiom: all journaled
'work' for a directory must be wholly contained within that directory.
Journals cannot reference tmpfiles or other objects outside the
directory. That would destroy our "every directory is a self-sufficient
WC" design. Hence the complete .svn/tmp/ area in every directory.
Ultimately, this means is that you can interrupt an update while it's in
the middle of doing all sorts of complex stuff in some subdirectory...
then move that inconsistent subdirectory to some other box, run 'svn
cleanup', and it will still be able to finish executing its journals and
get back to normal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 2 15:44:44 2004