subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gleason, Todd" <Todd.Glea...@elekta.com>
Subject RE: Update-Only Checkout Enhancement
Date Thu, 12 Dec 2013 16:01:13 GMT
> From: Ben Reser [mailto:ben@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@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.

Mime
View raw message