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

Re: svn commit: r12676 - branches/locking/subversion/libsvn_fs_fs

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-01-12 19:01:59 CET

"Brian W. Fitzpatrick" <fitz@red-bean.com> writes:

> I'll be coming through in a pass later today to turn most of the
> apr_file_FOO calls into svn_io_file_FOO calls with a nice neat SVN_ERR
> wrapper around it (which should clean up the code a good bit).

One difference between apr_ and svn_io_ is that the apr functions
accept paths in the system's native encoding while the svn functions
accept paths in UTF-8 and converts to native before calling apr. Now,
the locking paths are ASCII representations of MD5 sums are they not?
Does that mean that the encoding is irrelevant?

> I modified the code to use write_entries_file, which I
> modified to do an atomic write by using a temporary file. The only
> problem with this is that since I had been just appending to the file,
> I'm now rewriting it entirely--a performance hit, but I guess
> something that we'll have to live with to deal with to prevent writing
> half a hash to an entries file.

Do you modify an file more than once during a single operation? If so
then the WC code used to have a similar problem with the entries file.
It's much less of a problem now, see notes/entries-caching for some of
the gory details.

>>> + if (strncmp (buf, "K ", 2) == 0) /* We have a lock file. */
>>> + {
>>> + svn_lock_t *lock;
>>> + SVN_ERR (read_lock_from_hash_name (&lock, fs, child, fd,
>>> pool));
>>> +
>>> + apr_hash_set (*locks, lock->path, APR_HASH_KEY_STRING,
>>> lock);
>>> + }
>>> + else /* It's another entries file. Recurse. */
>>> + get_locks_under_path (locks, fs, abs_path, fd, pool);
>> SVN_ERR or svn_error_clear.
> Done.
>> You haven't closed fd.
> read_lock_from_abs_path closes it.

And that is called by read_lock_from_hash_name? I think that the call
to read_lock_from_hash_name warrents a comment about the closing of
the file.

> I could change the code so that I
> (the caller) always close the fd, but I was worried that if an
> svn_error_t was thrown before it returned to me, the file would never
> get closed. Thoughts?

The fallback is that the file will get closed automatically when the
pool passed to the open call gets cleared/destroyed. That is usually
sufficient for most errors.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 19:03:13 2005

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

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