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
Received on Tue Feb 27 12:07:20 2007