A wiki for this group

On Wed, Aug 6, 2008 at 2:24 PM, Ryan Schmidt <
subversion-2008c_at_ryandesign.com> wrote:

> On Aug 5, 2008, at 22:03, Martin_at_Cleaver.org wrote:
>
>> (How about using a wiki instead of the mailing list? I found the svn
>> vendor branch documentation just terrible for a newbie)
>>
> A wiki is not a substitute for a mailing list. A mailing list is for
> questions and answers, and for troubleshooting. A wiki is for documentation.
>

Ok. So keep the mailing list. Would the community benefit from a wiki for
documentation as well?

For those people not on the mailing list, who aren't in the conversation day
in day out, and who want a reference source a wiki could be really useful...
(and a wiki set up to file all email can be even more useful).

From http://subversion.tigris.org/tools_contrib.html search for the word
"vendor" - nothing. You'd need to look for svn_load_dirs.pl (which is an
obscure name, relative to "vendor branch"); From Blair's email I now know
that there is a tool "piston" that manages Subversion Vendor Branches, but
there's no "vendor branch" category and no other tools category "import",
and indeed, "piston" doesn't exist anywhere on this page. Even searching for
"rename" on this page yields no hits. Sure I could have sent an email, and
waited 24 hours. But I did ask on #svn and they pointed me back at
svn_load_dirs.pl, which after a lot of head scratching I worked out how to
use and build a tool to harness, only to find that it's impractical because
of the renaming issues.

The existing site is somewhat broken. For instance from
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=121964 I
click "Contributed tools" and get taken to the 404 at
http://subversion.tigris.org/servlets/tools_contrib.html ; if the site was a
wiki more people could help to maintain the site structure.

For instance, a wiki would have a page called SVN Vendor Branches that
collected the best ways of describing what one is and which tools can manage
them.

A wiki is not a substitute for a book either. A book is written and reviewed
by editors and formatted carefully and organized and changes are considered
before being accepted. Wikis accept all changes, some of which should never
have been accepted, or should have been in different places, or do not match
the style of the rest of the document. Especially in the case of the
Subversion book, I wouldn't change its process. I find it excellent.

Yup, the book like the old timers on the mailing list is written by people
who understand the concept. Wikis are open to newcomers who will inform you
of what they didn't understand and help experts frame complex ideas in
simple langauage.

I simply didn't understand the chapter on vendor branches, and neither did
these people:

"I use Subversion and a concept called 'vendor branches.' Sadly, their
documentation is confusing " -
http://lookfirst.com/2007/11/subversion-vendor-branches-howto.html

"I read the Subversion book, which confused me a bit and pointed me towards
svn_load_dirs, which has both a man page and a README, neither of which make
a great deal of sense. " -
http://burtonini.com/blog/computers/svn-vendor-2005-05-04-13-55

"I found the vendor branch concept a bit confusing;" -
http://techlog.p2061.org/2008/05/21/using-svn-for-application-deployment/

That's not to say it can't be improved in places. The writers welcome
feedback. You should send it to the book mailing list. Info about how to do
that is near the bottom of http://svnbook.org/ .

If it was a wiki I'd contribute. Indeed, probably the people who wrote those
blog posts would contribute.

A wiki is not a substitute for a book either. A book is written and reviewed
> by editors and formatted carefully and organized and changes are considered
> before being accepted. Wikis accept all changes, some of which should never
> have been accepted, or should have been in different places, or do not match
> the style of the rest of the document. Especially in the case of the
> Subversion book, I wouldn't change its process. I find it excellent.
>

The three bloggers plus myself would likely have contribute to the wiki page
on Subversion Branches. How many people write the Subversion Book? A wiki
would not substitute the book, it would complement it, by providing raw
material, tools and useful distinctions.

Just wanted to share my thoughts. I'm off to use Piston now. (Thanks Blair)

Martin

--
Martin Cleaver M.Sc. MBA
PS. Here's the script I wrote.
cat svn_create_vendor_branch.pl
#! /bin/perl -w
use strict; # don't use this, use Piston http://piston.rubyforge.org/
my $vendorurl="http://svn.automattic.com/wordpress-mu";
my $vendordroptag="1.2.3";
my $workingarea="/tmp/build-$$";
mkdir $workingarea;
chdir $workingarea;
my $repodir=$workingarea.'/repo';
my $repobase="file://$repodir";
my $reponame="mysite.com";
my $repourl="$repobase/$reponame";
my $repovendor=$repourl.'/vendor';
my $repowpmu=$repovendor.'/wpmu';
my $repomucurrent=$repowpmu.'/current';
my $repoproject=$repourl.'/project';
if ( ! -d $repodir ) {
    mkdir $repodir
}
chdir $repodir;
run ("svnadmin create $reponame");
run ("svn mkdir $repovendor -m 'All code from others than me'");
run ("svn mkdir $repowpmu -m 'Code from the $vendorurl wpmu team at
Automattic'");
run ("svn mkdir $repomucurrent -m 'Dir for wpmu current revision'");
export_and_load($vendorurl, $vendordroptag);
run ("svn cp $repomucurrent $repoproject -m 'Import of vendor branch
$vendorurl $vendordroptag'");
my $testcheckout=$workingarea."/checkout";
mkdir $testcheckout;
chdir $testcheckout;
run ("svn co $repourl");
print "Checked out to $testcheckout\n";
part2();
run ("find . -type d | grep -v .svn");
sub part2 {
    my @vendordroptags=qw(1.2.4 1.2.4rc1  1.2.5  1.2.5a 1.3 1.3.2
1.3.3  1.5-rc1 1.5.1);
    foreach $vendordroptag (@vendordroptags) {
   export_and_load($vendorurl, $vendordroptag);
    }
}
sub  export_and_load {
    my ($vendorurl, $vendordroptag) = @_;
    chdir $workingarea;
    run ("svn export $vendorurl/tags/$vendordroptag/");
    run ("svn_load_dirs.pl $repowpmu -t wpmu-$vendordroptag current
./$vendordroptag");
}
sub run {
    my ($cmd) = @_;
    print $cmd."\n";
    system $cmd;
}