[feature request]: prevent subversion from keeping track of changes

[Steffen Gumpert <me...@privacy.net>]

Hi,

I know the subject sounds a little strange to be a feature
request addressed to a version control system. So let me
explain: most development environments store their project-
oriented settings in text files within the project directory.
And most of this information changes very frequently
(nearly every commit) and is not a point of interest to
keep track of its changes. But some information (such as
the current version, release- and build-number the compiler
uses to generate the executable) is important. But indeed
not its history (moreover, one can run into trouble under
some circumstances).

To prevent the repository from beeing blown up by needless
information, I found it useful to be able to tell subversion
only to hold the latest version of a particular file
(lets say by a new property) and so overwrite the current
repository entry at each commit of this file. (The revision
number of this file should then always be 1 or 0 to show
this special treatment).

Would this be possible?

Thanks for your comments, Steffen.

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

Re: [feature request]: prevent subversion from keeping track of changes

["Ph. Marek" <ph...@bmlv.gv.at>]

On Monday 26 February 2007 22:28, Jared Hardy wrote:
> I just wanted to note that such a feature would be useful for large
> binaries, or compressed files, where everyone should have the latest
> version as part of any atomic update, but file diff history (except
> for path position and other low-cost meta-data) is not important.
> Storing diff history would take too much storage, and would be very
> inefficient for compressed files. A user-defined history-depth limit
> value definition method would be even better (the use-case example
> described here would be depth 1).
But you're aware that if you're storing only *one* version of the file, you 
cannot do delta-updates? That point may be void to you, but gzip has an extra 
switch:

    --rsyncable   Make rsync-friendly archive

Using that makes the generated files a bit larger, but they can be related to 
each other - so storing/transmitting deltas gets possible.

If you're only storing the last version, you have to transfer the full data to 
each client - which may not be practical!


Regards,

Phil

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

Re: [feature request]: prevent subversion from keeping track of changes

[Jared Hardy <ja...@gmail.com>]

On 2/23/07, Steffen Gumpert <me...@privacy.net> wrote:
> Hi,
>
> I know the subject sounds a little strange to be a feature
> request addressed to a version control system. So let me
> explain: most development environments store their project-
> oriented settings in text files within the project directory.
> And most of this information changes very frequently
> (nearly every commit) and is not a point of interest to
> keep track of its changes. But some information (such as
> the current version, release- and build-number the compiler
> uses to generate the executable) is important. But indeed
> not its history (moreover, one can run into trouble under
> some circumstances).
>
> To prevent the repository from beeing blown up by needless
> information, I found it useful to be able to tell subversion
> only to hold the latest version of a particular file
> (lets say by a new property) and so overwrite the current
> repository entry at each commit of this file. (The revision
> number of this file should then always be 1 or 0 to show
> this special treatment).
>
> Would this be possible?
>
> Thanks for your comments, Steffen.

I just wanted to note that such a feature would be useful for large
binaries, or compressed files, where everyone should have the latest
version as part of any atomic update, but file diff history (except
for path position and other low-cost meta-data) is not important.
Storing diff history would take too much storage, and would be very
inefficient for compressed files. A user-defined history-depth limit
value definition method would be even better (the use-case example
described here would be depth 1).

    Thanks!
    Jared

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

Re: [feature request]: prevent subversion from keeping track of changes

[Michael Sinz <Mi...@sinz.org>]

Steffen Gumpert wrote:
> Hi,
> 
> I know the subject sounds a little strange to be a feature
> request addressed to a version control system. So let me
> explain: most development environments store their project-
> oriented settings in text files within the project directory.
> And most of this information changes very frequently
> (nearly every commit) and is not a point of interest to
> keep track of its changes. But some information (such as
> the current version, release- and build-number the compiler
> uses to generate the executable) is important. But indeed
> not its history (moreover, one can run into trouble under
> some circumstances).

Why is it that you don't want to be able to fully recreate a
build from history?  That other build information is somewhat
important as it represents some state in history.

However...

> To prevent the repository from beeing blown up by needless
> information, I found it useful to be able to tell subversion
> only to hold the latest version of a particular file
> (lets say by a new property) and so overwrite the current
> repository entry at each commit of this file. (The revision
> number of this file should then always be 1 or 0 to show
> this special treatment).

If you modify your processes you could make this a revprop on
the initial version of the directory - they are not versioned
and thus do not clutter things.  The problem is that they don't
check out normally (you would have to do a propget and put the
output into your file) nor commit normally (required revprop
hook to allow changing it and taking the file and putting it
into the revprop via propset)

> Would this be possible?

In a backwards compatible manner, this is a client issue and can
be build using what I described above.  However, this is sub-optimal
for a number of reasons.

However, the concept of a file that does not get versioned - that just
scares me.  In the old RCS days, that could happen with RCS if the
command ever thought you had binary in the file (high-bit ASCII, etc)
and thus it would only store the "current" version.  I have lost the
history of a number of bits of source code from the 80's that I really
wish I had not lost.  If it is too easy to set such a behavior in a
repository, the same could happen (either due to accident or malicious
intent).  (The lack of ways to destroy data in the repository provides
a nice audit trail for companies that need to follow some documentation
processes/etc.)

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

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