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

["Teblin, Ivan" <Iv...@avertlabs.com>]

(Mailing here seems to be the only way to leave feedbacks, according to info
from SVN site)

I use SVN in Windows (don't know what is the version because svn.exe refuses
to show it despite all my efforts but I downloaded it couple of months ago).

After excitement about great abilities and smartness of server part of the
system, I've fallen to disappointment about exceptionally stupid way the
client part works with local files. The main problem: it does not honour any
FS-specific file data like extended attributes, permissions, linking info,
etc - nothing. I did not get my hands to source code yet, but after
experimenting with NTFS-permissions, my strong guessing that SVN client
creates temp files than tries to rename them into target names, so breaking
hard-links and spoiling NTFS ACLs.

If you, dev-guys, want to keep your code as much cross-platform as possible,
you should not do such weird thing because it's catastrophic for concistency
of various local attributes that SVN does not (and right: should not!) be
aware of. I guess that this way of treating files is necessary to work
around some other problems and I do appreciate your work of resolving them.
However, people must have choice, don't they? So, why not to introduce an
option of only-basic-file-io, so disabling such complicated and destructive
behaviour but enabling simply overwriting files instead? This modification
is excellently cross-platform, no needs to know just anything about NTFS,
Windows, whatever, except normal UNIX-like file I/O operations.

P.S. Before writing you I googled about the problem and have seen many
opinions something like "it's only for people working on Win2000+ _and_
using NTFS, hence it's quite rare, so no reason to bother with it". I can
bet that such opinions were issued by *NIX-only users not strongly involved
in Windows administration and development, so I strongly disagree with their
opinion because:

-  Win2000 is the first Windows version providing (at last!) OS-level
security and good usability, and its default FS choice _is_ NTFS, in fact M$
strongly discourages using FAT FS.

- Despite the fact Explorer is stupid about NTFS-links, it does work with
NTFS-ACLs and many popular file managers (like FAR that I use) work with
NTFS-links as well without any problems. SVN is targeted to advanced users
and computer specialists, so don't expect those people would restrict
themselves from using this great FS feature simply because of some stupid
M$-programs like Explorer (and regretfully, current SVN-client... :-((( ).

- All new computers in all my local computer shops do contain pre-installed
WinXP, of course with NTFS as default FS. And most corporate
IT-administering and software development is based on Win2000+ OSes and
there's no any evidence about changing the things from that direction in
near future (despite of my personal preferences to keep away from M$).

I do hope, my report and my SVN impressions will help you to make the right
decision and improve even more your great product.

Ivan

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

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

Ben Collins-Sussman wrote:

>
> On Dec 2, 2004, at 8:06 AM, Teblin, Ivan wrote:
>
>>
>> I do hope, my report and my SVN impressions will help you to make the 
>> right
>> decision and improve even more your great product.
>>
>
> I think the problem here is defining the term "portability".
>
> We use APR to be "portable", which in this case means, "Subversion 
> runs on every OS".  APR allows this to happen by only making available 
> those features that exist in every OS -- the greatest common subset, 
> nothing more.
>
> 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.

_Or_ Unix permissions, most of the time.

>   That's a much harder task, and I'm not sure that even a stated goal 
> of the project.

It certainly is not.

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

[Ben Collins-Sussman <su...@collab.net>]

On Dec 2, 2004, at 8:06 AM, Teblin, Ivan wrote:
>
> I do hope, my report and my SVN impressions will help you to make the 
> right
> decision and improve even more your great product.
>

I think the problem here is defining the term "portability".

We use APR to be "portable", which in this case means, "Subversion runs 
on every OS".  APR allows this to happen by only making available those 
features that exist in every OS -- the greatest common subset, nothing 
more.

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.  That's a 
much harder task, and I'm not sure that even a stated goal of the 
project.


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