Ben Collins-Sussman wrote:
> On Aug 3, 2005, at 2:34 AM, John wrote:
> > They're all about keeping updates out of the versioned repository
> > until ready, while still being able to share them around. When a
> > shelveset is deleted it's gone forever.
> And why is this important? Is the permanent storage of patches going
> to use up all your disk? I imagine that only very, *very* few people
> are watching disk space so closely.
Well, it is. I have for instance only ~50 GB on a backup tape, so
this is sort of a 'magic boundary' for our current work flow.
Anything added permanently (as in 'Really Permanently') is a potential
I work around this by having 'long term, almost pure text' projects
and 'anything else' which might include temporary binaries.
With one project per repo I can cull the not-so-important repos
from time to time by either deleting them completely or by
replacing them with a new repo containing only HEAD and/or a
few tags. This, unfortunately, loses 'by design' the history.
> Maybe it would matter if 'shelved' patches are all huge multi-
> gigabyte changes to large binary files, but that seems like an
> extreme edge-case.
We have tons of maps which are basically binary or combined
text/binary data. What you describe as 'as extreme edge-case'
is daily work here.
> It sounds like the feature is meant for code patches.
Or maps for that matter.
If I had a wish for free, I'd wish for a bit more flexibility
in the checkin/checkout process.
I can e.g. convert a map into a textual representation, even
in a form where small changes to a map will result in small
text diffs. The problem is that this text form is neither
usable for our applications (don't understand that format)
nor exceptionally suitable to be stored uncompressed somewhere
(far too large).
So ideally, I'd like to be able to specify converters
.map <-> .txt and .txt <-> .compressed and have svn work
on the .txt representation when doing its internal diff/
patch stuff and possibly using the .compressed version
for archiving. The user should only see the .map version
in the working copy [and for storage reasons it would be
nice if the .txt version wouldn't be stored in the .svn
directories either, but that'd be a bonus]
Maybe this is already possibly nowadays, but then I have not
been able to figure out how to do it.
PS: Btw, note that there is a similar process already
active: Line endings conversion, so I don't think there is
a conceptional problem involved here. [Of course it will
be the user's responsibility to set up the converters
correctly, I don't think storing the converter in the
repo and making sure it will work on any client is
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Aug 4 08:11:47 2005