Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

[Norbert Unterberg <ne...@gmx.net>]

Ben Collins-Sussman schrieb:

 > It sounds like your frustration is that Subversion is not completely
 > "ported" to any one OS.  It doesn't understand or preserve NTFS ACLs,
 > nor does it understand or preserve Unix hardlinks or devices.

Even without understanding all these concepts, Subversion could still 
preserve them.

I have seen this topic discussion on the list before, and as previous, I 
find the response from the subversion developer(s) a bit unfair.

I understand the situation as follows (please correct me if I am wrong):

It is o.k. for Subversion to ignore and not care about standard and 
extended file attributes like ownership, security, attached streams etc. 
However, to not know about these things and yet leave them intact, 
Subversion needs to preserver the *identity* of a file. When modifying 
files, Subversion currently creates a new temp file from scratch, works 
on that, and finally renames the temp file to the original file's name, 
destroying the original file with all the attributes. Basically you 
create a new object and destroy the original object, instead of applying 
changes to the original object.

If subversion would would create a backup of the file's *content* in a 
temp file and then make the modifications on the original file, then all 
the attributes would be preserved, and the code would still be fully 
portable.

Wasn't one of Subversion fundamental rules not to destroy user's data? 
Are file attributes/security part of user's data?

Norbert

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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

[Branko Čibej <br...@xbc.nu>]

Norbert Unterberg wrote:

> Could you please define the term "atomic replacement"? I do not know 
> of a portable (ANSI-C OS-independent) way to replace one file by 
> another in one atomic opearation.

"Portable", when it comes to manipulating files, is almost never "ANSI-C 
OS-independent".

> You need to push the original file aside before renaming the new one 
> to the original name, and that makes it two operations,

No. What you describe /used/ to be true on Windows, but no longer is. 
These days Windows lets you do what Unix allowed since day one, that is, 
rename a file over an existing target. And that rename is atomic.

> leaving the working copy without the "real" file for a short moment.
> Or did I miss something?

Yes. :-)

-- Brane



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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

[Greg Hudson <gh...@MIT.EDU>]

On Sun, 2004-12-05 at 17:14, Norbert Unterberg wrote:
> On windows starting with XP, there is a new function ReplaceFile() which 
> gives you both: Atomic file replacement with preservation of all attributes.

I would be fine with using ReplaceFile() on Windows when available, at
least in principle.

(But I'm not a Windows developer, so I'm not going to put the work into
it.  And I'm not certain how this would actually be done.  Perhaps there
would be a new apr_file_replace() which mirrors apr_file_rename() but
which, on Unix, matches some metadata aspects of the source file to the
target file before performing the rename.  This raises questions of
whether apr_file_replace should be trying to match the file ownership,
and if so whether it should fail silently or loudly if the user can't
make chown() or chmod() calls.)


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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

[Norbert Unterberg <ne...@gmx.net>]

Greg Hudson schrieb:

> We have a choice between atomic replacement (which means working copy
> files won't be left in intermediate states, which is good) and
> preserving the file identity.  

On windows starting with XP, there is a new function ReplaceFile() which 
gives you both: Atomic file replacement with preservation of all attributes.

> I think atomic replacement is the right choice

Could you please define the term "atomic replacement"? I do not know of 
a portable (ANSI-C OS-independent) way to replace one file by another in 
one atomic opearation. You need to push the original file aside before 
renaming the new one to the original name, and that makes it two 
operations, leaving the working copy without the "real" file for a short 
moment.
Or did I miss something?

Norbert

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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

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

Greg Hudson <gh...@MIT.EDU> writes:

> On Sun, 2004-12-05 at 14:29, Philip Martin wrote:
>> Patches, as ever, welcome!  Is that unfair?
>
> It's unfair if we won't accept the patches.
>
> We have a choice between atomic replacement (which means working copy
> files won't be left in intermediate states, which is good) and
> preserving the file identity.

If the change were only to apply to changes made while running a log
file then the intermediate states would be irrelevant.  It's far from
trivial to make Subversion behave this way, but I think it could be
done.

> I think atomic replacement is the right
> choice; even if we back up file contents before overwriting them, users
> won't necessarily know where to look for the backups.

User's probably wouldn't need to know, only "svn cleanup" would ever
have to deal with them.

> And we're far
> from the only tool which performs atomic replacement to update files.

Agreed, although some tools, e.g. (x)emacs, allow the user to choose.

-- 
Philip Martin

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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

[Greg Hudson <gh...@MIT.EDU>]

On Sun, 2004-12-05 at 14:29, Philip Martin wrote:
> Patches, as ever, welcome!  Is that unfair?

It's unfair if we won't accept the patches.

We have a choice between atomic replacement (which means working copy
files won't be left in intermediate states, which is good) and
preserving the file identity.  I think atomic replacement is the right
choice; even if we back up file contents before overwriting them, users
won't necessarily know where to look for the backups.  And we're far
from the only tool which performs atomic replacement to update files.


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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

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

Norbert Unterberg <ne...@gmx.net> writes:

> I have seen this topic discussion on the list before, and as previous,
> I find the response from the subversion developer(s) a bit unfair.

> If subversion would would create a backup of the file's *content* in a
> temp file and then make the modifications on the original file, then
> all the attributes would be preserved, and the code would still be
> fully portable.

That's possible, although if it involves additional copying it might
not be welcomed by those that already think Subversion is too slow.
One would have to make sure that repeating an interrupted operation
didn't cause the backup to get overwritten with junk.

Patches, as ever, welcome!  Is that unfair?

-- 
Philip Martin

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