[Libxml2] Getting Started

[Ross Bamford]

(I sent this earlier, but it doesn't appear to have made the list.  
Apologies if this turns up as a dupe).

On Fri, 10 Aug 2007 15:25:39 +0100, TRANS <transfire at gmail.com> wrote:

> First post to the new list. Glad to see so many people have made it
> --some 32 subscribers by last count.
>

Cool.

> The first thing I think we should do, now that we have the repo, is to
> clean it up a bit. I was thinking that perhaps the libxml, libxslt and
> the www directories should all have their own branches/tags/trunk. Is
> that a good idea? Or is it better just to leave as one?

Hmm, I'm not sure on that one. It would work, and might be cleaner, but it  
might also make it more difficult to get libxslt-ruby compiled from SVN,  
since it has a compile-time dependency on the libxml-ruby code, and  
expects it to be at ../libxml. So it'd add an extra step at checkout, but  
on the flipside it would make it easier for people to get the right  
libxslt for the libxml from a specific release tag.

If we're gonna do this, we should do it soon though, since (I think?)  
it'll mean everyone with a checked-out copy checking out again.

> We certainly
> need to clean up the arrangement, whatever we do. The repo currently
> looks like this:
>
>   [...elided...]
>
> I'd like to get rid of anything we don't need and get consistent
> naming across the board. Suggestions? (Ross maybe you can advise
> here).
>

Well, I think the CVSROOT can go for a start. Also, DEV_0_4 is already  
merged down to trunk, so that can go as well - along with it's root tag.  
I've not done much branching/merging with SVN, but I assume we still need  
the root tag for the MAINT_0_3_8 branch? The 'libxslt' branch can also go,  
I'm not sure where it came from actually, and the same goes for the 'init'  
tag.

I'd suggest we then go forward, tagging releases as previously, but  
including 'libxslt' in the tag too, to make it easier to get a compatible  
codebase for both libraries from a tag. Branching can be done on major  
releases, and as needed, to allow maintenance on the old version (in the  
branch) and work on the new version (in trunk) and backporting of fixes  
etc.

How's that sound?

Cheers,
-- 
Ross Bamford - rosco at roscopeco.co.uk