[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN Unversioned/Non-atomic Commits?

From: Pat Suwalski <pat_at_suwalski.net>
Date: 2006-11-09 21:28:53 CET

Hello Duncan,

Duncan Murdoch wrote:
>> However, the same atomic commits are causing me a headache. My CVS
>> auto-building scripts use a small dot-file in the directory for every
>> project to keep track of when things were last built, versions of
>> certain libraries on the build machine, and other such metadata.
> That sounds like something produced during the build. Normally you
> wouldn't version control such a thing. You version control the stuff
> produced by humans, not the stuff that can be easily reproduced by the
> machine. (You might make an exception to this rule if the build process
> is very slow, or if you want a snapshot of the build output, but
> normally it's a good rule.)

It is produced during the build, but it is automated and must be based
on information from the previous build. But the changes are useless to
any human, so bumping the revision is undesirable.

The idea here is to just keep the metadata with the project, so that a
person checking it out can view it. Also, if the information was stored
outside of SVN, it would be very prone to getting lost in the buzz of
things moving around, branches, etc.

> If some parts of this file need versioning and other parts change with
> each build, then the usual trick is to put the versioned parts in a
> different file, and copy from that file during the make. The versioned
> file will change rarely, the non-versioned file will change with every
> build.

Are you implying that SVN can do non-versioned files? What is needed
here does not need normal version tracking at all, but needs to branch
with the rest if the project.

>> We have considered doing a one-time check-in of a dot-file, and then
>> always modifying the unversioned metadata of that single
>> file/revision. This should work, I think.
> I think that sounds like the usual solution.

Thanks for the suggestions.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 21:29:06 2006

This is an archived mail posted to the Subversion Users mailing list.