Hello again,
Duncan Murdoch wrote:
>> 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.
<snip>
>
> 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.
Yes, it is in an official capacity. I should have been more precise with
my example. Developer checks code in, when a build happens over night,
the official build script notices changes, bumps the version number,
produces a versioned package (a .deb in this case). It needs to put that
last version number back in the repository so that the next time it runs
N+1 can be used.
Using the SVN commit number would actually technically work for version
numbers, but it's a large number that increases by more than 1 per build.
> 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.
Another solution that would work, though it would really screw with the
idea of an atomic commit, would be to have the automated system somehow
check in the modified file into the _same_ revision as the project was
checked out from. I have no idea how this could/would work, but it would
solve the problem. I imagine anyone reading this is cringing at the
suggestion.
> 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.)
I can understand that. It's just from the human point of view it would
be nice to have commits that allow for some sort of automated checkin
without mucking with the whole repository, interfering with how humans
experience that repository.
--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 22:07:42 2006