Re: How to administer the binaries

Thanks both,

I'm quite relieved at all that - I wasn't relishing having to get back into CVS! I'll do a read-only checkout and get myself set up with git locally.

As for the binaries I'll walk before running - my first aim will be a 10.6 Intel. I'd found the source for the Privoxy Utility; I've not yet had any responses from the users mailing list and I find the utility occasionally useful, so I plan to bundle it.

Cheers,

Ian



On 2011-11-25, at 10:38 AM, David Schmidt wrote:

> On 11/25/2011 10:02 AM, Fabian Keil wrote:
>> Ian Silvester<[email protected]>  wrote:
>> 
>>> So I can use the simple read-only CVS access to grab the current source
>>> and build a binary, but what's the procedure for providing it back to
>>> the project for hosting? And what if I'd like to store some the
>>> configuration files back in CVS? I suppose what I'm asking is, should I
>>> have read-write CVS access, since I am aware that if I start with a
>>> read-only working copy then I can't commit changes from that; I'd need
>>> to create a replacement working copy if/when I have read/write access?
> 
> You can use Fabian's idea with git below; or you could provide diffs/patches for the changes you've made.  That would make it easy for any of us to try the patches out before commitment.
> 
>> Not necessarily, changing the repository information should suffice.
>> 
>> Personally I would recommend that you do not work directly
>> with a CVS checkout, though, but use git-cvsimport and do
>> the development with git.
>> 
>> That's what I've been doing myself for several years now and it
>> has improved my work flow quite a bit. I currently have 35 branches
>> in my local Privoxy repository and having to maintain them in CVS
>> would waste a lot of time.
>> 
>> If you were using git, you could also easily send patches to this
>> list for review and wouldn't require CVS write permissions right away,
>> which I currently wouldn't feel comfortable to grant, especially while
>> the CVS commit mails are down (and I have no stable Internet connection).
>> 
>> Importing from CVS into another distributed version control system
>> (like Mercurial) should work, too, but I'm less familiar with it
>> and probably wouldn't be much help in case of problems.
>> 
>> We also have the following TODO list item for a while now:
>> | 54) Move away from CVS to a more modern revision control system.
>> |     Find out if there are any objection against going with Git.
>> |     Using Git would also have the advantage that SF now pretents
>> |     to support it, so we could do it independently from 53).
>> 
>> I would feel more comfortable if the OS X binary packages
>> weren't uploaded to the SF project site right away, unless
>> they are built by David based on your changes or at least
>> tested and reviewed by people we already know.
> 
> Quite right.  Those aforementioned patches would be an easy way to get that done.  I use Eclipse myself, and it has an easy "generate patch" menu option... I'd imagine xcode does as well.
> 
> >> P.S. Question for you David - so far as you know will Xcode running
> >> on 10.6 on an Intel MacBook allow me to create binaries for PPC
> >> and/or 10.4 targets?
> 
> Well, yes and no.  There are a lot of differences in the way the code needs to be installed on all levels of OSX... 10.4, 10.5, 10.6, and now 10.7.  So while you can generate a binary, generating an installable package is an entirely different matter.
> 
> - David


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d