[Chandler-dev] Using svn instead of builds for tarballs?

Andi Vajda vajda at osafoundation.org
Thu Nov 9 22:45:22 PST 2006


On Thu, 9 Nov 2006, Heikki Toivonen wrote:

> Andi Vajda wrote:
>> On Thu, 9 Nov 2006, Heikki Toivonen wrote:
>>> * If svn is available, but builds is not, you may be unable to build
>>> chandler
>>
>> if svn is unavailable, you're also unable to build.
>
> Yes, but as it stands currently, if *either* svn *or* builds is
> unreachable you may be unable to build. We've already had these
> situations with the recent network outages where svn was there but
> builds was unreachable. If everything was in svn, there would be one
> less place to break.

I know, I know.... the logic is incomplete though, if svn tends to be 
unavailable more often than builds, then putting all eggs into the svn basket
would be unwise. I sure don't know that that is the case, I was just not 
convinced by the argument...

>>> * Tarballs are not versioned
>>
>> They sure are, look at their names...
>
> Ok, I didn't think this one thoroughly. But in theory we could let svn
> version the tarballs instead of doing it with names (although I am not
> advocating that).

I'd be against renaming or modifying in any way source tarballs produced by 
outside organizations (what external is mostly used for).

>
>>> * Tarballs are not protected from corruption/tampering when downloading
>>
>> And svn checkouts are ? how so ?
>
> Like I mentioned, when you use svn+ssh. By its nature it encrypts the
> connection and verifies that nothing changes over the wire.

How is that more secure than downloading source tarballs over ssh, https ?

>
>>> * Need separate accounts and tools to upgrade and deal with builds
>>
>> That could be construed as an advantage...
>
> It could, but I think it is mostly a disadvantage. Besides, if we put
> the tarballs into a separate svn repository with separate access
> controls then we would get the same account separation but with fewer tools.

True.

> The main difference is that it would simplify the system.

There is something to be said for that although I don't see that today's 
system is broken (that was the point of my earlier reply).

My main concern is that I'm not sure svn is such a great tool for handling 
large files. I could be wrong... If we follow this route, maintaining the 
separation between external/internal and chandler is important.

Andi..


More information about the chandler-dev mailing list