Re: Files changed on svn update

[Ben Collins-Sussman <su...@collab.net>]

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

Mac Resource Forks - Possible (programming solution)?

[Mark Dawson <mc...@mac.com>]

<I just joined this list, and wasn't sure how to reply to the original 
thread about issues with Mac resource forks and file meta data>

It seems like one (long term) solution to the issue would be to "add" 
to the Mac OS Client.,
using  a concept similar to file bundles--the data fork, resource fork, 
and any future metadata could be split up using what subversion already 
has--text and binary comparisons.  It would also allow storing on 
non-metadata supporting file systems by saving the "file" as a 
directory with sub files.  That would also allow the saving of the file 
name--the full unicode name could be stored in a separate sub file, 
just in case the hosting file system (or even subversion) didn't 
support unicode, long file names, etc.  "All" it might take is to add a 
wrapper functionality to the front-end (client).  The client would 
"intercept" downloads of special folders (maybe foldername.<some 
extension>?), and convert them into one Mac file (doing "merges" and 
"unmerges")  It should be possible for the client to be smart enough to 
update only the data fork or resource fork.  The server would just see 
normal file/folder traffic.  It seems like the only piece that would 
effect the overall subversion project would be in marking the file 
bundle directory in some way that the client sw would know to merge it 
that would be compatible with the normal subversion system…

mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Files changed on svn update

[Philip Martin <ph...@codematters.co.uk>]

Ben Collins-Sussman <su...@collab.net> writes:

> 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?

I suspect it is the "incomplete" flag.  If I'm right the entries file
first gets written with "incomplete=true" and later gets written
without the flag.  I suppose it might be possible to delay writing the
incomplete flag--perhaps by using a flag in the access baton and
writing the incomplete flag the first time some other change is made.
Then it should be possible to avoid writing the entries file at all if
no changes are made.  A minor complication is that the code needs to
handle the case where the entries file starts out incomplete but no
changes need to be made.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org