Comments on Issue #525 and Issue #908:Optional or compressed text base storage

[martin budden <mj...@gmail.com>]

I'd like to state that I'd really like to see the storage of text bases made
optional. In particular I'd like to see the following three
user-configurable options offered:

a) text bases as they are (ie no change)
b) no text bases
c) no text bases, but hash of the file stored in .svn directory - this would
allow you to see that a file has been changed, although you wouldn't be able
to do diffs.

There is a fourth option:
d) compressed text bases

I have no objection to this, but it's not useful to me.

Why would I like this? Well it's because I am using subversion in a slightly
unusual way: I've put my Windows "My Documents" folder under version
control. I have several repositories, including one for "My Pictures" - this
is the one where optional text bases would be really useful. And you see why
I'm not bothered about compressed text bases: they wouldn't buy anything for
JPEG files.

Why did I do this? Well, my view of backup is having multiple redundant
copies of files.  When I copy my photos to my PC I then want to (eventually)
propagate them to my partner's PC, my NAS, two external USB drives (one
which lives at the office as an off-site backup) etc. I haven't found any
backup software that has this usage model, but subversion handles it like a
treat. The only downside is the storage space taken up by the text bases.

Additionally I rarely edit my photos, but I do organise them into
directories, and also create directories of slideshows. Again subversion
handles this like a treat.

The text bases are not too much of a problem on the PCs or the NAS, but they
are problematic for external USB drives (I like to use self-powered 2.5 inch
drives which are of limited capacity), and they are extremely problematic if
I want to use subversion to copy a slideshow onto a USB keyfob.


(Oh, by the way, I also use subversion for software development.)

Re: Comments on Issue #525 and Issue #908:Optional or compressed text base storage

[Karl Fogel <kf...@google.com>]

"martin budden" <mj...@gmail.com> writes:
> I guess the fact that you have answered my posting means that no-one
> is working on this and that you are following your rule of "reply to
> all postings". (I've just read "producing open source software",
> excellent book. A few colleagues at work joke that you could have
> called it "producing software" and 90% of it would have still
> applied.)

If only I were able to reply to all postings! :-)

I've heard recently that someone may be starting to work on optional
text bases.  There have been false alarms on this before, so don't
jump for joy yet.

(Thanks for the nice mention of the book, too.  I like to think it's
more about volunteer communities than about software per se, but that
may a fantasy.)

> Anyway, getting back on topic, I thought you might store a hash: I
> included it in my posting for completeness. The main reason for my
> posting was to add my voice to those asking for this feature, and to
> give a reason why non-existant textbases should be prioritised over
> compressed ones (though from the issue list #2539 needs to be done for
> both).

It's funny, it's one of those things that everyone agrees is important
(and I think most people agree that non-existent text bases are more
important than compressed text bases), but no one thinks it's
important enough to work on.  It's not the easiest problem in
Subversion, but it's certainly not the hardest either.  Someday,
someday...

-Karl

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

Re: Comments on Issue #525 and Issue #908:Optional or compressed text base storage

[martin budden <mj...@gmail.com>]

Karl,

I guess the fact that you have answered my posting means that no-one is
working on this and that you are following your rule of "reply to all
postings". (I've just read "producing open source software", excellent book.
A few colleagues at work joke that you could have called it "producing
software" and 90% of it would have still applied.)

Anyway, getting back on topic, I thought you might store a hash: I included
it in my posting for completeness. The main reason for my posting was to add
my voice to those asking for this feature, and to give a reason why
non-existant textbases should be prioritised over compressed ones (though
from the issue list #2539 needs to be done for both).

Unfortunately I don't have anywhere enough bandwidth to volunteer to help
out, but maybe next year if it's still outstanding (but I sincerely hope
it's not).

Anyway, thanks for taking the trouble to answer my posting.

Martin

On 8/7/06, Karl Fogel <kf...@google.com> wrote:
>
> "martin budden" <mj...@gmail.com> writes:
> > I'd like to state that I'd really like to see the storage of text bases
> made
> > optional. In particular I'd like to see the following three
> user-configurable
> > options offered:
> >
> > a) text bases as they are (ie no change)
> > b) no text bases
> > c) no text bases, but hash of the file stored in .svn directory - this
> would
> > allow you to see that a file has been changed, although you wouldn't be
> able to
> > do diffs.
>
> Note that we store a hash of the text-base already (see the
> .svn/entries file).  It is a way to do corruption checks.
>
> For text-base-less working copies, we'd want to store a hash of the
> working file too.  This gets tricky, because if someone changes the
> svn:keywords or svn:eol-style property, the working file can change
> without it being "modified" in the sense that we usually mean by that
> word.  Not an impossible problem, just a subtlety to watch out for.
>
> There is no reason to do (b) but not (c).  If we allow text-base-less
> working copies, we should unconditionally keep a working file checksum
> and use it to detect when the file has been modified.
>
> Totally agree that solving #525 would be a Good Thing, by the way! :-)
>
> -Karl
>

Re: Comments on Issue #525 and Issue #908:Optional or compressed text base storage

[Karl Fogel <kf...@google.com>]

"martin budden" <mj...@gmail.com> writes:
> I'd like to state that I'd really like to see the storage of text bases made
> optional. In particular I'd like to see the following three user-configurable
> options offered:
>
> a) text bases as they are (ie no change)
> b) no text bases
> c) no text bases, but hash of the file stored in .svn directory - this would
> allow you to see that a file has been changed, although you wouldn't be able to
> do diffs.

Note that we store a hash of the text-base already (see the
.svn/entries file).  It is a way to do corruption checks.

For text-base-less working copies, we'd want to store a hash of the
working file too.  This gets tricky, because if someone changes the
svn:keywords or svn:eol-style property, the working file can change
without it being "modified" in the sense that we usually mean by that
word.  Not an impossible problem, just a subtlety to watch out for.

There is no reason to do (b) but not (c).  If we allow text-base-less
working copies, we should unconditionally keep a working file checksum
and use it to detect when the file has been modified.

Totally agree that solving #525 would be a Good Thing, by the way! :-)

-Karl

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