[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: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-11-09 21:17:19 CET

On 11/9/2006 3:04 PM, Pat Suwalski wrote:
> Hello,
>
> I'm in the process of moving a fairly large CVS repository to SVN. We
> really like SVN, the atomic commits and ability to move files are an
> absolute pleasure for developers.
>
> 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.)

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.

>
> This was not a problem with CVS, but with SVN, whenever such a file is
> checked in (up to 10 times a day), the version of the whole directory
> structure gets bumped and real log messages will get somewhat lost in
> all the noise.
>
> We considered using non-revisioned tags, but those too are per commit
> rather than per-file/directory. Ideally we could make it metadata
> pertaining to each projects' directory, or some file within each
> directory that does not bump the version of the whole repository.
>
> 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.

Duncan Murdoch

>
> Do any experts have any advice?
>
> Thank you!
> --Pat
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
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:18:03 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.