On 11/9/2006 3:28 PM, Pat Suwalski wrote:
> 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.
I think we are probably using "build" differently. I was thinking a
build was what you get when you run "make". In my use of the word,
everyone who checks out the project and makes it gets their own build,
so it doesn't make sense to have version control for the output of the
build.
It sounds as though you are thinking of a build as a more official
thing, done centrally and shared. If that's the case, then I'd suggest
that the central machine that does the build should save build
information somewhere for distribution, but Subversion is not
particularly good at that. It is for version control, and what you want
is something like rsync.
> 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.
I'd suggest that you have a "builder-mode" in which that file gets
produced, and a "user-mode" in which the rule to make that object is to
copy it from the central machine. Then everyone just makes the project
(or the metadata part of it) and gets the file, without having tons of
copies of it in your repository.
>
>> 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.
It can ignore files, but it's not a distribution system for unversioned
files. (It's a fairly common request to ask for such a thing, but it's
not really consistent with a version control system. If someone wants
to check out the project as it was at a particular revision, then they
want everything from that revision, not just some things.)
Duncan Murdoch
>
>>> 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.
>
> --Pat
---------------------------------------------------------------------
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:40:06 2006