Noob Question: Build number

[Dustin Sallings]

   Well, you can't have both decentralization and a centralized number  
authority.  They are incompatible goals.

   You *can* have a centralized release mechanism built on top of your  
distributed revision control where developers all go and meet to  
exchange changesets.  The build can number however makes sense to it  
(buildbot will make sequential numbers by default, or you can use the  
serial number from the central build server).

   It's good practice to have something luke buildbot running anyway.   
It can react quickly to your changes and tell you if anyone broke a  
test.  Moreover, it's a hands-off build system to help you provide  
builds to qa.

   I realize it's not the most perfect mapping to your current mode of  
operation, but the centralization features are simply to allow the  
exchange of code.  What you're asking for is peripheral to that.

-- 
Dustin Sallings (mobile)

On Nov 26, 2007, at 16:40, blr at robertsr.us wrote:

>>
>>    You don't need to involve any sort of centralized server or  
>> anything
>> of the sort.  It's terribly prone to race conditions, and you can't
>> possibly get it right.
>
> Are you saying the "Single Central Repository" model (CVSLikePractice)
> won't work?  I was hoping to make the changes required minimal at  
> first,
> and this is documented on the wiki and the hgbook, so I was assuming  
> it
> would be a good first step for a 10-15 developer team using CVS.
>
>>    identify tells you the working tree version (i.e. what the user is
>> working on).  If a user has fixed a bug as of version f4ff14558153,
>> then that's all you need to recreate the tree.  Other branch changes,
>> incoming changes that haven't been applied or merged yet, changes  
>> that
>> occurred ``after'' the fix, etc... are not interesting to you.
>>
>
> I'm not sure if I'm not understanding what you're recommending, or if
> you're not understanding what I'm asking (I'm new to drcs).   
> Developers
> check in fixes for a day or 2 before a new build goes out to the test
> servers.  The testers need to know which fixes are in the build.  If  
> the
> build number is 175, then all the defects that are fixed in builds  
> <= 175
> should be fixed.  Any that got checked in after the CI machine  
> updated and
> built (fixed in > 175) aren't fixed in that build and shouldn't be
> re-tested yet.
>
> I have a hard time seeing how I can use the hash for that since it  
> isn't
> sequential, but I'm more than willing to admit that I'm missing  
> something.
>
> Thanks,
> Barry Roberts
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>