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..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
