Kean Johnston [jkj@sco.com] wrote:
> The third possible value, "copy_on_edit" should be almost
> self-explanatory.
> It implies a new client side command, "svn edit". With this text-base
> method, when a client retrieves a WC, it simply stores a checksum and
> date/size properties for the files in a flat-ASCII file in .svn. If the
> user wants to edit the file, they first issue an "svn edit" command with
> the name of the file. This command then copies over the current file
> contents into .svn/text-base, and marks the entry in the flat-ASCII file
> as being edited. This then allows the user to do local diffs, revert
I agree with you that this is wasteful. On the typical small opensource
project it doesn't matter much, but it doesn't scale well to large projects.
I do think it is a useful feature though, and I like your approach of
just making it optional.
However, I really don't like the concept of having to do a command for
each file I'm going to edit. This seems like a lot of unnecessary hassle.
I have an alternate proposal for copy-on-edit. Do the checksums, but
instead of svn edit, just wait until the user actually tries to run a
command that requires the original source, then pull that down and keep
it around until the changed file gets checked in.
This gets you the benefit of not having a complete copy of the sources,
and subsequent calls that require the source would be fast/cheap.
svn co ....
<edits>
svn diff (file gets downloaded)
<edits>
svn diff (runs off of previously pulled pristine copy)
svn commit (diff is sent, pristine copy gets deleted)
I honestly have not even looked at much of the svn code, so I
have no idea how workable this thought is. I'm just throwing it
out there for consideration.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 18 23:44:09 2002