[wx-dev] SVN is ready for use

[Robin Dunn]

Vadim Zeitlin wrote:
> On Tue, 26 Jun 2007 09:17:42 -0700 Robin Dunn <robin at alldunn.com> wrote:
> 
> RD> > VS> What about wxAutohacks? Or is it not relevant anymore 
> RD> > VS> (build/autogen.mk fails without it)?
> RD> 
> RD> Sorry, I was going to ask about that but forgot.
> ...
> RD> Where do you want it?
> 
>  I think about just importing its files under build/autoconf_prepend or
> something, I don't see why should it be a separate module (but then maybe
> I'm missing something).

ok.

> 
>  BTW, didn't we decide to put wxPython at the same level as wxWidgets (and
> not under it)? At least from the disk space (and checkout time) point of
> view it would be nice to do it like this as right now you always get it as

I considered it but then I realized that if I pulled it out as part of 
the CVS conversion then all of the history of things that deal with both 
wxWidgets and wxPython would be broken.  Once things settle down a bit 
then we can move things around in the repository without messing up the 
old revisions.

> I don't think there is any way to checkout just some of repository files
> with svn (is there?).

You can easily get just a subtree, and I think you can also graft 
subtrees together in your workspace into a different structure.  So one 
possible approach to take is to move all of the top-level items except 
for wxPython down into a sub directory, such as "wx" or whatever.  Then 
it would look like this:

	/trunk/wx/art/
	/trunk/wx/build/
	...
	/trunk/wxPython/

Then people wanting to work on just wxWidgets would checkout /trunk/wx 
and those wanting just wxPython would get /trunk/wxPython, and those 
wanting both could first get wx and the checkout the wxPython subtree 
inside that working dir, then their workspace would look the same as it 
does now.

Another approach I didn't think about until too late that might have 
been better is to use a single repository instead of multiples like we 
have now, and then put each "project" at the top level, each with it's 
own trunk, branches, and tags subdirs.  Like this:

	/project1/trunk
	/project1/branches
	/project1/tags
	/project2/trunk
	/project2/branches
	/project2/tags
	...

In this case I would make the sandbox, wxWebSite, etc. be projects, and 
also would import the cvs into a project named "cvs" that I would make 
read-only and then copy wxPython out of there up to the project level, 
and also everything else up to another dir at the project level. 
Actually the more I think about this the more I think that it might be 
worth the hassle of doing another migration.  Thoughts?


> 
>  And, while I'm asking svn questions, would anyone know how to view the
> differences between revisions of the same file on 2 branches with viewvc?
> This is something you need to do very often (what changed between 2.6 and
> 2.8 in this file?) but I don't see how to do it.

I don't either.  It probably boils down to the fact that in subversion 
branches are just alternate paths with separate histories.  Although 
subversion knows where the branched files came from originally there 
probably isn't an easy way for ViewVC to find out what the branch or tag 
paths are for a specific file.  Theoretically it could assume the 
pseudo-standard "trunk, branches, tags" dir structure, and make some 
guesses based on that, but it would probably slow down ViewVC quite a 
bit.  If you can find another web tool that is branch aware I'd be happy 
to try and install it.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!