I had some talks with Eduard Bloch (the author of svn-buildpackage) and
Eddy Petrisor (as a contributor listed in its uploaders field) and it
seems that both of them lost their interest in svn-bp and/or are too
busy to take care of current development. Some time ago I started fixing
some of the bugs but then discovered that some of those need bigger
improvement in svn-bp's code.
Thinking about all that I started redesigning svn-bp (actually I started
redesigning the code but in the end it's become more) and after writing
some code I want to stop here and wait for comments, suggestions and
criticism first (before doing too much in the wrong direction).
=== Why the changes? ===
svn-buildpackage (with its scripts svn-inject and svn-upgrade) is a
collection of logically structured system calls which invoke other
binaries via shell (mainly svn commands of course). That lead to
inconvinient issues, e.g. having to authenticate for every single svn
call. Another problem came up with packages with many files. For some
shell commands all files were listed as arguments, this leading to a
shell failure because of too many lines.
So, to get rid of these shell commands I wanted to use SVN::Client and
other perl libraries. I tried to implement it in current code but that
was too hard to do.
Then there were layout problems (layout meaning the repository layout in
this case). At the moment svn-bp knows two different layouts but there
were requests for new ones. Implementing more layouts seems pretty hard
because layout specific code is to be found everywhere in the scripts.
Another reason for rewriting at least some of the code is Format: 3.0
(quilt). Some parts of svn-bp rely on a diff.gz; those need to be able
to deal with debian.tar.comp as well which is not as easy as I thought
in the first place.
=== So, what's the new idea? (implementation) ===
I started writing a class SvnBp::Repository which wraps some SVN::Client
functions and implements the layout types (those are actually in
subclasses SvnBp::Repository::Layout[1-3]). Having this structure it's
easier to add new layouts. And the big win (IMO) is the interface to the
repository which is of course layout independent (you can always give
'branches/lenny' as arguments and the object knows the exact URL for the
Another class I started writing is SvnBp:
pack which is a wrapper for
everything related to the package. It's supposed to know commands like
get_upstream, get_full_source, build and so on. (Yes, the idea is to
have short and readable svn-* scripts in the end.)
This all wouldn't automatically mean any changes for our users, but...
=== What about more ideas? ===
Well, there is another one: removing svn-inject and svn-upgrade and
moving that functionality to svn-buildpackage which now knows 'operation
modes'. svn-inject would then be 'svn-buildpackage inject' (and of
course there will be symlinks from svn-(inject|upgrade) to
svn-buildpackage which then starts the correct mode automagically).
The idea is to make svn-buildpackage more like a layer over svn with
package building functionality
. That means that I intend to implement
more subversion typical commands in svn-buildpackage, e.g. switch or
checkout. Since svn-bp then knows about the layout it's possible to do
svn-buildpackage checkout branches/lenny svn+ssh://alioth.d.o/whatever/package
or similar (not yet implemented
I think that it's still possible to leave the command line options
unchanged which is convinient for already written scripts around svn-bp.
About the config file of svn-bp I'm not sure yet. I'm thinking about
changing it completely to have a file with groups (maybe even group
names as regexps) which would be nice for people who work in group
maintenance and alone. But that's still just an idea.
=== Where to find what? ===
A summary (or whatever it is) can be found in the wiki at:
The code (without a debian dir and any documentation) is in the svn-bp
subversion repository (in collab-maint) as branch/0.7:
=== Why am I telling you that? ===
1. Like probably almost everyone else in this project I need help to get
ready faster (the code is *far* from usable!).
2. As I already said I don't want to implement everything and then see
you disagreeing completely with me.
So, this is your chance to tell me that everything was wrong and I'm a
stupid moron who should go home -- or you send patches, whatever you
like better. Also, you can now send in wishes for 0.7; I'll try to
consider all of them.
If you want to help me (which I very much appreciate) please contact me
off list; almost everything is possible!
And now, go, rip me up! :-)