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

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

Thanks for answer,

I think a feature "simple file overwriting" I'm suggesting here, is
something that does exist in every OS, hence it's extremely compatible. As
you can see from my report, I definitely stated that SVN should _not_ be
aware of any OS-specific features because all filesystems contain more
features than you guys have time and will to support it. However, I
expressed my concern that for some reason SVN does not implement a simple
way to _automatically_ be compatible with whatever filesystems' features but
doing something complicated and non-compatible instead.

It must be a simple fix regarding only file-saving routine and I hoped you
would concider it easy to develop. Anyway, if you think there're some
difficulties to implement it, I'll try to get my own hands to SVN sources
and implement a patch to add the suggested "extra-compatibility" option for
overwriting files instead of renaming/deleting them. Any suggestions how to
name the option? "--fastsave"?

Ivan


> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Friday, December 03, 2004 5:39 PM
> To: Teblin, Ivan
> Cc: 'dev@subversion.tigris.org'
> Subject: Re: SVN need to delete/create-temp/rename files instead of
> simply ove rwriting them (suggestion how to workaround)
> 
> 
> 
> 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

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

Ben Collins-Sussman <su...@collab.net> writes:

> On Dec 5, 2004, at 5:33 AM, Teblin, Ivan wrote:
>>
>> It must be a simple fix regarding only file-saving routine and I
>> hoped you
>> would concider it easy to develop. Anyway, if you think there're some
>> difficulties to implement it, I'll try to get my own hands to SVN
>> sources
>> and implement a patch to add the suggested "extra-compatibility"
>> option for
>> overwriting files instead of renaming/deleting them. Any suggestions
>> how to
>> name the option? "--fastsave"?
>>
>
> I don't think we would accept such a patch.

I don't think it's even feasible to implement such a patch.

There are two files, the pristine text-base and the working file.
Update sends a diff (in vdelta format) and this gets combined with the
text-base to produce a new text-base.  I don't think there is an easy
way to do this "in place" as applying the vdelta requires the original
text-base.

Once the new, temporary, text-base is available a log file is written
containg commands to construct the new working file and to move the
text base into place.  If the working file has local mods this
involves a three-way merge between the two text-bases and the working
copy, so both text-bases are required.  If the working file is
unmodified it is a direct copy of the text-base only if svn:keywords
and svn:eol-style are unset, otherwise translation is required.  All
these create a temporary working file, and the log file commands cause
both text-base and working file to get moved into place.

Your original problem was the loss of NTFS meta-data caused by the
moves.  I suppose you could replace the final moves with copies into
the existing files, but you would lose the atomic guarantees that
Subversion currently gives.  I suspect any such additional copy would
be slower than the current move so "--fastsave" is not appropriate :)

I encourage you to think about libsvn_wc improvements, but please
understand that it's complicated stuff.

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

[Ben Reser <be...@reser.org>]

On Sun, Dec 05, 2004 at 07:55:19PM +0100, Norbert Unterberg wrote:
> Please help me: What is so important to make the working copy file 
> operation atomic? Couldn't the file could be locked during the 
> operation? If a svn crash or interruption is your concern, the user 
> needs to run svn cleanup afterwards anyway, which could take care of the 
> incomplete operation when it finds the temp file.

I'm reading this thread with massive delay so please excuse me if you've
already figured this out.  However, nobody seems to have given you the
answer to your question, Why is atomic file replations so important?

Many times we're taking your working copy file, that contains your local
changes and applying changes from the remote server.  That file contains
the only copy in the world of these changes until you commit it.  If we
replace the file in place, i.e. non-atomically, then the part of the
file would only exist in memory.  If the computer were to lose power
before the write would finish then part of the data would be lost.  

If you're talking about file system level locks, they can't resolve this
problem, they can only resolve race conditions.  The only way locks
could solve this issue would be to completely change the model that
subversion uses to handle revision control from copy-modify-merge to
lock-modify-commit-unlock.  The latter model doesn't have to worry about
merging server changes into files you have locally modified, because
while you're working on a file nobody else can modify it.

So any attempt to remove the atomic replacement functionality in the wc
code is risking your local modifications everytime you run svn up and is
downright foolish.

-- 
Ben Reser <be...@reser.org>
http://ben.reser.org

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken

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

> [...] The renaming that you see 
> happening in .svn/ is quite deliberate, and it's used to guarantee that 
> files come into existence atomically.   

What procedure are you using to replace the original file in one 
operation? Usually the required delete-rename or rename-rename-delete 
operations are still distinct operations, and there is a moment where 
the original file does not exist in the working copy.

> File data arrives slowly from 
> the network, spooled into a tmpfile, then the tmpfile is moved to be 
> come the "real" file in one step.

Please help me: What is so important to make the working copy file 
operation atomic? Couldn't the file could be locked during the 
operation? If a svn crash or interruption is your concern, the user 
needs to run svn cleanup afterwards anyway, which could take care of the 
incomplete operation when it finds the temp file.

BTW, on Windows you could use the ReplaceFile() API where available. 
That would make both parties happy...

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)

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

On Dec 5, 2004, at 5:33 AM, Teblin, Ivan wrote:
>
> It must be a simple fix regarding only file-saving routine and I hoped 
> you
> would concider it easy to develop. Anyway, if you think there're some
> difficulties to implement it, I'll try to get my own hands to SVN 
> sources
> and implement a patch to add the suggested "extra-compatibility" 
> option for
> overwriting files instead of renaming/deleting them. Any suggestions 
> how to
> name the option? "--fastsave"?
>

I don't think we would accept such a patch.  The renaming that you see 
happening in .svn/ is quite deliberate, and it's used to guarantee that 
files come into existence atomically.   File data arrives slowly from 
the network, spooled into a tmpfile, then the tmpfile is moved to be 
come the "real" file in one step.  This isn't something special -- it's 
an incredibly common technique with nice benefits.


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