Re: [Fwd: CVS to Subversion move progress]

On Fri, Jun 26, 2009 at 12:21 AM, till <klimpong@gmail.com> wrote: > On Thu, Jun 25, 2009 at 4:23 PM, Greg Beaver<greg@chiaraquartet.net> > wrote: > > Daniel O'Connor wrote: > >> But what about: > >> > >> * pearweb (multiple packages, 1x directory) - suggest merging back > >> into one uberpackage > >> > > > > Hi Daniel, > > > > Seriously, this is backwards thinking. The reason the package was split > > up was because it was impossible to maintain as one uberpackage (this > > may have been before your time in PEAR, I'm not sure). > :D It was. From where I'm standing, the biggest driver for splitting things up was probably having the news / index pages as separate - however, there's now an RSS feed which changes that requirement a bit. The uberpackage comment - yeah, I know, I know; it's a bit messy to do it; but it does solve the problem. Till; the problem is packages like pearweb and validate have source code in a bunch of different spots. IE: Validate_AU and Validate_IT would look like: Validate/ Validate/package_AU.xml Validate/AU.php Validate/tests/validate_AU.phpt Validate/package_IT.xml Validate/IT.php Validate/tests/validate_IT.phpt Previously, pear cvstag package_AU.xml would just take all of the Validate_AU files and tag them with a specific release. SVN's tagging is just a copy-entire-directory structure - so all of Validate/ gets tagged as the Validate_AU 1.2.3 release Shifting to a Validate_AU and Validate_IT directory structure solves the problem, and that's a lot easier in SVN than it was in CVS to do; so that's an easy fix. However, other packages - MDB2, Date_Holidays, etc need to have a think about it; and choose to either restructure the directories the code is in or come up with a way the svntag command should work which is comparible to CVS' tagging, or decide it's not really that important anyway and do nothing. . This results in > > more stuff being included than we want, but one can't work around this > > flaw in subversion very easily. > What we do at work to deal with this problem is to tag with a specific time / date; then when we svn export that code, it's got a revision number in it. If the exported package.xml got a $Id$ rendered in it (say, <!-- as a comment -->) that would be a cheap and quick hack so you can tell where a given PEAR package started life from (revision 12345). All of this being said, I've never used the CVS tags beyond typing 'pear cvstag' and wondering what's happening in the background. I rarely use svn tags at work as a comparison point (we do branch lots though, and I compare those two lots), or for anything more than drawing a line in the revision log. So... now that I say this all out loud, I'm in favour of just doing the really simple svntag command (copy dir A to B) and ignoring the problems with it until someone complains loudly.