[PD-dev] svn:externals "sucks", or tracking changes in Gem

[zmoelnig at iem.at]

some of the autobuilds have been failing for ages now, because of a  
change introduced into Gem's directory layout, the autobuild system's  
adaption to it and some somewhat out-of-sync autobuild hosts.

Subject: [PD-cvs] autobuild: pd-main+libs debian-testing-i386
Subject: [PD-cvs] autobuild: pd-puredyne debian-testing-i386
Subject: [PD-cvs] autobuild: pd-main+libs ubuntu-hardy-i386 2008-08-26

all of these are failing, because of the following history:
- Gem has switched form CVS to SVN
- the autobuild system (or rather: the human that is behind that:  
hans) has tracked Gem's switch to svn
- i have tidied up Gem a bit and moved the "manual/" into the "doc/" section
- hans has adapted the autobuild system accordingly
- somehow some machines got out of sync: they have updated their  
autobuild system to include the change in the directory layout, but  
are still using the CVS version of Gem (where this change has not yet  
occured)
- these machines fail to build each night

i think it is related to the re-occuring (e.g. see the current thread  
on flext-svn) discussion of svn:externals

as i can see it, there are 2 main arguments against svn:externals
- (fear of) problems when doing "svn update" (e.g. due to unofficial  
certificates)
- (fear of) problems when re-structuring the repository (e.g. when  
importing code that was previously integrated via svn:externals)

as can be seen by the example above, also the alternative approach  
(using scripts to explicitely checkout a remote repository) is not  
foolproof (well nothing is), and actually exhibits the very problems  
because of which it is used (apart from legacy reasons for sticking to  
them)


mfg.dsr
IOhannes




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.