RE: Update-Only Checkout Enhancement

> From: Ben Reser [mailto:ben_at_reser.org]
> Absolutely, the answer here isn't a one size fits all. Nobody is
> objecting to
> the idea of allowing this. The problem is that the code is not
> designed to
> allow this and it's a ton of work to change that. I can think of a
> good 10
> other things that would require the same level of effort that would
> improve
> things for a lot more people

Should you get into doing this, I hope it will be highly configurable both from the server side and client side.

I can definitely see running a checkout operation where you'd like to specify that for anything under a certain URL within your checkout, you don't want pristine (just what I presume would be sufficient metadata like dates+hashes to detect any changes that may occur). Or after fetching, you might want to "prune" out the pristines for a file or directory tree. You may or may not change the files afterward, and as folks have noted, you'd have to fetch down from the server in any commit operation, and you'd have to do a double-fetch of sorts (working base plus intended revision) in order to update in cases where such a file had been locally altered.

Note that this pruning sort of behavior may require maintaining client-side metadata, perhaps similar to how changelists are client-side.

You would also want to be able to configure on the server something like svn:no-pristines to say that by default there would be no pristine in any working copy that downloaded a given file/path, and then you'd need to do some opposite logic from any client that did want the pristines. This could be good when most people don't work in a given area, but you want to accommodate the few people who do by letting them demand the usual structure.

And yes, it's icing on the cake, though I can certainly imagine using it. I have enough working copies that disk space is very much an issue for me.

> Once you no longer need a pristine there are a lot of potential
> scenarios that
> require different behaviors. So it's not even a simple matter of just
> changing
> the working copy library to support pristines not existing. It becomes
> thinking about how to deal with these scenarios (not that all of them
> need to
> be implemented immediately, but you probably want to not pigeon hole
> yourself
> into an implementation that doesn't support them).
>
> Some files don't delta very well and essentially change every bit when
> the file
> changes, so those files update and commit are better off just
> transmitting full
> text. Some files do delta fine but are just large, if you change the
> file you
> may want to run a diff and update/commit would benefit from deltas.
>
> If you have a file that deltas well should you download the full text
> from the
> server and produce a delta locally or just send the full text to the
> server?
> The answer to this depends on the network. If you're on a asymmetric
> connection where upload or download or different whichever method that
> sends
> the largest data over the fastest direction is better (e.g. a typical
> DSL or
> Cable internet connection where download is faster it may be far better
> to
> download full text and upload the delta you calculate). If you're on a
> symmetric network you just do whichever takes the least work (directly
> sending/retrieving full text). Due to laptops that came move between
> networks
> you also can't just configure the file on the server side (i.e. set a
> property).

You do what you have to do based on what's in the WC (which is determined by server and client configurations). If you're committing without a pristine, I think you must either send the whole new file, or else re-receive the working base file from the server. That is, unless you do something like running checksums/hashes on fragments of the file to pinpoint changes, which you might do if the file is really large, or (my preference) if a particular svn: attribute was set on the file/folder.

Of course for doing updates, if you can determine based on the file's metadata (checksum/hash info) that the file hasn't changed, then the usual diff should still function.

> What about compressing the file. If it compresses well then you could
> have
> your cake and eat it too... You save disk space and you still have the
> pristine.

I don't think this gets you very far. Probably worth doing, but I wouldn't see it as the ultimate answer.

> The user may want us to retain the pristine data we retrieved to
> execute a
> command or they may just want us to destroy it immediately to limit
> disk space.

Exactly, and that's where the client-side configuration I described above would come into play.

> For that matter the pristine store as of 1.7 doesn't even remove files.
> So if
> you're updating a working copy it will just continue to grow. As of
> 1.8 we use
> this to allow faster updates when you already have a copy of a version
> of a
> file in the pristine store. So we need some sort of "garbage
> collector" for
> the pristine store even for the setup that has it:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4071

Yes, very much so.

> So all in all it's not a matter of throwing a simple option in and
> being done
> with it. I realize that your particular use case is probably one of
> the
> simpler ones to deal with. But it's by far the least common use case
> that we
> hear complaints about with respect to the pristine store.
>
> Please realize that considerable thought has gone into this. It's just
> not
> done yet.

As always you have to prioritize. Note though that http://subversion.tigris.org/issues/show_bug.cgi?id=525 is 12 years old. With WC-NG available now, perhaps it's time to consider this.

Todd C. Gleason | Senior Software Engineer
Elekta
100 Mathilda Place, Fifth Floor
Sunnyvale, CA 94086, United States
Office: +14086782640 |
Todd.Gleason_at_elekta.com | www.elekta.com

Please consider the environment before printing this e-mail.

The contents of this e-mail message (including any attachments) are confidential to and are intended to be conveyed for the use of the recipient to whom it is addressed only. If you receive this transmission in error, please notify the sender of this immediately and delete the message from your system. Any distribution, reproduction or use of this message by someone other than recipient is not authorized and may be unlawful.
Received on 2013-12-12 17:02:03 CET