[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: <kfogel_at_collab.net>
Date: 2003-09-23 23:01:59 CEST

Jim, it would be very difficult for us to make a risky change like
this at this stage. We could consider it after 1.0, but doing it now
would be inviting unforseen consequences (perhaps portability
related), which we'd then have to deal with. Sorry :-(.

-K

Jim Sokoloff <jim@sokoloff.com> writes:
> 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:51:08 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.