[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pear-dev
Subject:    Re: [PEAR-DEV] [Fwd: CVS to Subversion move progress]
From:       "Daniel O'Connor" <daniel.oconnor () gmail ! com>
Date:       2009-06-25 22:54:26
Message-ID: 106cc1200906251542s7afead97j4eeb7cb6d668f610 () mail ! gmail ! com
[Download RAW message or body]


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.


[prev in list] [next in list] [prev in thread] [next in thread]