[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 22:35:49 CET

On 11/9/2006 4:07 PM, Pat Suwalski wrote:
> 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 just using the SVN revision number at the time of the build.
   I can't think of many situations where it really matters that you're
skipping some numbers.

Duncan Murdoch

>
>> 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

---------------------------------------------------------------------
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:36:40 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.