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

Proposed functionality change: change svn_io_copy_file to [optionally] preserve links

From: Jim Sokoloff <jim_at_sokoloff.com>
Date: 2003-09-23 23:16:39 CEST

Background:

We use hard links in our development environment. (These are hard links
FROM a subversion working copy TO a re-arranged working copy that
developers actually do their edits in. There are some historical
reasons for this, but by and large, we're stuck with it for the next
3-6 months.)

I'd like to have these links preserved across svn operations (commit with
keyword substitutions, update, etc), but the underlying implementation of
svn_io_copy_file does a create-temp-file and rename, which naturally
breaks the hard links.

(For comparison, what I'm attempting to do is analogous to setting Emacs'
variable 'backup-by-copying' to t.)

What I'm proposing is to (optionally, by user config setting) give up the
atomicity provided by the rename in favor of an implementation of
svn_io_copy_file that does a create-temp-file and then as the last
step calls
  return svn_io_file_copy (dst_tmp, dst, APR_FILE_SOURCE_PERMS, pool);

(which would preserve the hard links).

Notes:
1. This is my first time actually reading the core code for
subversion. I don't claim to know my way around yet, nor to
have a feeling for the project gestalt.

This change is trivial from a technical standpoint, for the cases that
I've thought about. What I'm asking for feedback on is:

2. The name of the config option to control this behavior?
3. Any caveats that people more familiar with the code can provide.
4. Am I so far off-base with this request that I should reconsider what
I'm asking for?

Thank you,
---Jim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 23:17:39 2003

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.