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

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

From: Jim Sokoloff <jim_at_sokoloff.com>
Date: 2003-09-23 23:31:50 CEST

I realize that hard links are themselves "non-directional", but I was
trying to convey that these links are NOT intra-working-copy, but between
a subversion working-copy and another location(s) on the disk, in a
one-to-many fashion.

I could have proofed the original post a little better perhaps.

---Jim

On Tue, 23 Sep 2003, Jim Sokoloff wrote:

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

---------------------------------------------------------------------
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:32:42 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.