[wx-dev] SVN is ready for use

[Robin Dunn]

Vadim Zeitlin wrote:

> RD> > I don't think there is any way to checkout just some of repository files
> RD> > with svn (is there?).
> RD> 
> RD> You can easily get just a subtree, and I think you can also graft 
> RD> subtrees together in your workspace into a different structure.
> 
>  Yes, but you can't easily do it for all directories but wxPython.

I know.

> 
> RD> So one possible approach to take is to move all of the top-level items
> RD> except for wxPython down into a sub directory, such as "wx" or
> RD> whatever.
> 
>  I.e. you'd prefer to have wxPython in the same repository? I'm asking
> because I thought you'd actually be glad to have a separate one for it as
> this would solve all these tagging problems (when wxPython releases don't
> use quite the same files as wxWidgets ones) so I'm a bit surprised by this.

Keeping it in the same repository is the best way to keep it connected 
to it's history.  I suppose that I could dump the old revisions and load 
them into a new repository, but then there would be two sets of the 
history for wxPython.  The tagging issue would be solved by giving 
wxPython it's own tags dir, or doing it like outlined in the other idea 
below.


> 
> RD> Then people wanting to work on just wxWidgets would checkout /trunk/wx 
> RD> and those wanting just wxPython would get /trunk/wxPython, and those 
> RD> wanting both could first get wx and the checkout the wxPython subtree 
> RD> inside that working dir, then their workspace would look the same as it 
> RD> does now.
> 
>  Wouldn't it be confusing though? Because if you just check out trunk they
> wouldn't look the same...

It would definitely be for advanced users only, and maybe only I would 
be interested in it.  ;-)  As an example, in my workspace I now have the 
branches that are being worked on by the wxPython GSoC students, but 
only the actual subtree's they are working on, and I have located them 
next to same the subtree from trunk.

> 
> RD> Another approach I didn't think about until too late that might have 
> RD> been better is to use a single repository instead of multiples like we 
> RD> have now, and then put each "project" at the top level, each with it's 
> RD> own trunk, branches, and tags subdirs.
> ...
> RD> Actually the more I think about this the more I think that it might be 
> RD> worth the hassle of doing another migration.  Thoughts?
> 
>  To be honest I don't really see what the advantages of having all projects
> in the same repository are. They would share the same revision numbers but
> I don't know if it's an advantage at all. What else does this change?

Continuity of the history, only one set of hooks scripts and other 
server-side things to maintain but still being able to have a separate 
set of tags and branches for each of the projects.  Also once we have 
this scheme in place it would be easy to promote other things up to 
project status, or to merge something from the project level down into 
the core if that need ever comes up, all with preserving the continuity 
of the history.

> 
> RD> If you can find another web tool that is branch aware I'd be happy to
> RD> try and install it.
> 
>  I know that Vaclav likes Fisheye (http://www.cenqua.com/fisheye/) which he
> uses for Bakefile. It's a commercial product but they provide free hosting
> for open source projects (but you can also apparently receive a free open
> source licence too). It does seem to handle branches in svn projects better
> and we wouldn't seem to lose anything by asking them to host it for us...

I'll take a look.

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