You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2008/09/17 01:46:19 UTC
Release Management for 1.6.x
Hello all,
Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
how to avoid that situation in 1.6.x. These are some of my ideas, and
ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
release.
Branching 1.6.x will happen sometime during the first couple weeks of November.
This is flexible, but we should try to be as close to that time frame as
possible. If features aren't quite ready for release by that time, we'll can
pull 'em and they can wait for 1.7. We already have enough new features to
justify a release by the end of the year.
As soon as the branch happens, I'll roll 1.6.0-pre1. I'll continue with weekly
-preX releases until there are no known issues, as which point I'll roll
1.6.0-rc1. If we don't have any known issues when we branch, I'll skip the
-preX series. The purpose of the -preX series is to get code from the branch
released soon and often, even if we are still working on stabilizing known
issues. Hopefully your testing environments are well scripted by now. :)
Once 1.6.0-rc1 is released, I'll follow the standard soak process, with a final
RC the week before release. Release Candidates should be just that: code which
is ready for release, and which we'd feel perfectly comfortable releasing as the
final release. Let's not have 11 "release candidates" before we find one we can
actually release.
I don't think these ideas are radically different than we've previously done,
just a little bit more formalized. Feedback is welcomed and encouraged.
-Hyrum
Re: How to become a build-bot [was: Release Management for 1.6.x]
Posted by km...@rockwellcollins.com.
Lieven Govaerts <sv...@mobsol.be> wrote on 09/18/2008 03:21:18 PM:
> Mark Phippard wrote:
> > On Wed, Sep 17, 2008 at 4:59 PM, <km...@rockwellcollins.com> wrote:
> ..
> >> But it confirms what I was afraid of. I would need to open up some
> >> machines more than our network overlords would like. I was hoping
> >> I could setup some type of nightly process which would then inform
> >> the buildbot master of the status via something less intrusive like
> >> email.
> >
> > I have the same issue and I recall Lieven said that it can in fact be
> > done. He'd need to provide the details. I think your Buildbot just
> > needs to run when it wants to (can poll for changes of course) and
> > then it can send the results to the master.
> >
>
> There are two options basically:
> 1. you only run the slave at certain times of the day/night. The master
> will combine all outstanding jobs and trigger the slave as soon as it
> connects. Disadvantage is that there's no way as far as I know to stop
> the buildslave gracefully, so if there's a build in progress that
> results in a FAIL mail to svn-breakage. If you want to do one nightly
> build per slave, than I can schedule that at a certain time and you just
> make sure the slave is online at that time. Then you kill it 2 hours
> later so you're sure no build is in progress.
> Note that it's always the slave that connects to the master, over HTTP.
> No incoming connections need to be enabled. However, you are giving a
> remote software and person (ie. me) access to execute arbitrary shell
> commands in the slave environment.
>
> 2. you do not use a buildslave, but send the results of a build to
> svn-breakage. This was the pre-buildbot method, but AFAIC still valid.
> The scripts we used for those nightly builds are in
> trunk/tools/test-scripts@2560. They were deleted afterwards so probably
> not really up to date.
>
> I prefer option 1; but would be equally happy if you implement option 2.
Probably have to go with option #2. While the environment could
be locked down for #1, it still probably would not be authorized.
For #2, I'm thinking of just running a nightly build and email results
back.
Might take me awhile to look at the old scripts though...
Kevin R.
Re: How to become a build-bot [was: Release Management for 1.6.x]
Posted by Lieven Govaerts <sv...@mobsol.be>.
Mark Phippard wrote:
> On Wed, Sep 17, 2008 at 4:59 PM, <km...@rockwellcollins.com> wrote:
..
>> But it confirms what I was afraid of. I would need to open up some
>> machines more than our network overlords would like. I was hoping
>> I could setup some type of nightly process which would then inform
>> the buildbot master of the status via something less intrusive like
>> email.
>
> I have the same issue and I recall Lieven said that it can in fact be
> done. He'd need to provide the details. I think your Buildbot just
> needs to run when it wants to (can poll for changes of course) and
> then it can send the results to the master.
>
There are two options basically:
1. you only run the slave at certain times of the day/night. The master
will combine all outstanding jobs and trigger the slave as soon as it
connects. Disadvantage is that there's no way as far as I know to stop
the buildslave gracefully, so if there's a build in progress that
results in a FAIL mail to svn-breakage. If you want to do one nightly
build per slave, than I can schedule that at a certain time and you just
make sure the slave is online at that time. Then you kill it 2 hours
later so you're sure no build is in progress.
Note that it's always the slave that connects to the master, over HTTP.
No incoming connections need to be enabled. However, you are giving a
remote software and person (ie. me) access to execute arbitrary shell
commands in the slave environment.
2. you do not use a buildslave, but send the results of a build to
svn-breakage. This was the pre-buildbot method, but AFAIC still valid.
The scripts we used for those nightly builds are in
trunk/tools/test-scripts@2560. They were deleted afterwards so probably
not really up to date.
I prefer option 1; but would be equally happy if you implement option 2.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: How to become a build-bot [was: Release Management for 1.6.x]
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 17, 2008 at 4:59 PM, <km...@rockwellcollins.com> wrote:
>
> "Mark Phippard" <ma...@gmail.com> wrote on 09/17/2008 10:01:39 AM:
>> On Wed, Sep 17, 2008 at 10:53 AM, Julian Foad
>> <ju...@btopenworld.com> wrote:
>> > kmradke@rockwellcollins.com wrote:
>> >> Suppose one has access to some fairly beefy hardware on multiple
>> >> platforms (solaris x86, windows, linux) that have a fair number of
>> >> spare cycles.
>> >>
>> >> What does it take to become a buildbot?
>> >
>> > Me too! Only without the beefy hardware or the multiple platforms.
>>
>> Start here:
>>
>> http://svn.collab.net/repos/svn/trunk/tools/buildbot/slaves/README
>
> Thanks for the pointer. I should have been able to find that myself.
>
> But it confirms what I was afraid of. I would need to open up some
> machines more than our network overlords would like. I was hoping
> I could setup some type of nightly process which would then inform
> the buildbot master of the status via something less intrusive like
> email.
I have the same issue and I recall Lieven said that it can in fact be
done. He'd need to provide the details. I think your Buildbot just
needs to run when it wants to (can poll for changes of course) and
then it can send the results to the master.
I have machines that can be used as well and would also need this
feature. I tried setting this up in the run-up to 1.5 and could not
get Buildbot installed on RHEL. Just ran out of time and forgot about
it, but can take it up again.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: How to become a build-bot [was: Release Management for 1.6.x]
Posted by km...@rockwellcollins.com.
"Mark Phippard" <ma...@gmail.com> wrote on 09/17/2008 10:01:39 AM:
> On Wed, Sep 17, 2008 at 10:53 AM, Julian Foad
> <ju...@btopenworld.com> wrote:
> > kmradke@rockwellcollins.com wrote:
> >> Suppose one has access to some fairly beefy hardware on multiple
> >> platforms (solaris x86, windows, linux) that have a fair number of
> >> spare cycles.
> >>
> >> What does it take to become a buildbot?
> >
> > Me too! Only without the beefy hardware or the multiple platforms.
>
> Start here:
>
> http://svn.collab.net/repos/svn/trunk/tools/buildbot/slaves/README
Thanks for the pointer. I should have been able to find that myself.
But it confirms what I was afraid of. I would need to open up some
machines more than our network overlords would like. I was hoping
I could setup some type of nightly process which would then inform
the buildbot master of the status via something less intrusive like
email.
Kevin R.
Re: How to become a build-bot [was: Release Management for 1.6.x]
Posted by Julian Foad <ju...@btopenworld.com>.
On Wed, 2008-09-17 at 11:01 -0400, Mark Phippard wrote:
> On Wed, Sep 17, 2008 at 10:53 AM, Julian Foad
> <ju...@btopenworld.com> wrote:
> > kmradke@rockwellcollins.com wrote:
> >> Suppose one has access to some fairly beefy hardware on multiple
> >> platforms (solaris x86, windows, linux) that have a fair number of
> >> spare cycles.
> >>
> >> What does it take to become a buildbot?
> >
> > Me too! Only without the beefy hardware or the multiple platforms.
>
> Start here:
>
> http://svn.collab.net/repos/svn/trunk/tools/buildbot/slaves/README
Thanks!
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: How to become a build-bot [was: Release Management for 1.6.x]
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 17, 2008 at 10:53 AM, Julian Foad
<ju...@btopenworld.com> wrote:
> kmradke@rockwellcollins.com wrote:
>> Suppose one has access to some fairly beefy hardware on multiple
>> platforms (solaris x86, windows, linux) that have a fair number of
>> spare cycles.
>>
>> What does it take to become a buildbot?
>
> Me too! Only without the beefy hardware or the multiple platforms.
Start here:
http://svn.collab.net/repos/svn/trunk/tools/buildbot/slaves/README
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
How to become a build-bot [was: Release Management for 1.6.x]
Posted by Julian Foad <ju...@btopenworld.com>.
kmradke@rockwellcollins.com wrote:
> Suppose one has access to some fairly beefy hardware on multiple
> platforms (solaris x86, windows, linux) that have a fair number of
> spare cycles.
>
> What does it take to become a buildbot?
Me too! Only without the beefy hardware or the multiple platforms.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release Management for 1.6.x
Posted by km...@rockwellcollins.com.
Lieven Govaerts <sv...@mobsol.be> wrote on 09/16/2008 10:05:14 PM:
> Hyrum K. Wright wrote:
> > Hello all,
> >
> > Since the 1.5.x release process fiasco, I've been doing a lot of
thinking about
> > how to avoid that situation in 1.6.x. These are some of my ideas, and
> > ultimately they form the basis of how I'm planning on proceeding with
the 1.6.0
> > release.
> >
> ...
> >
> > Once 1.6.0-rc1 is released, I'll follow the standard soak process,
with a final
> > RC the week before release. Release Candidates should be just that:
code which
> > is ready for release, and which we'd feel perfectly comfortable
releasing as the
> > final release. Let's not have 11 "release candidates" before we find
one we can
> > actually release.
> >
>
> One way to avoid that is to have a clear view on when features are
> ready. Given the clearly defined time box, I propose to define some
> dates when certain checks and decisions can be made:
>
> I'm thinking of:
> - somewhere beginning October: look at the existing features and decide
> what needs to be done to finish them for 1.6.
> - mid October: fix the regressions introduced in trunk. A number of
> tests have been marked as XFail on trunk in the last weeks (double
> delete, tree conflicts). Some of them are due to changed behavior,
> others due to regressions.
> - continuously, end October at the latest: look at the test results of
> the buildbots and make sure all tests pass on all tested platforms
> (including serf). We could do with some more buildbots, especially for
> bdb testing.
Suppose one has access to some fairly beefy hardware on multiple
platforms (solaris x86, windows, linux) that have a fair number of
spare cycles.
What does it take to become a buildbot?
Kevin R.
Re: Release Management for 1.6.x
Posted by Lieven Govaerts <sv...@mobsol.be>.
Hyrum K. Wright wrote:
> Hello all,
>
> Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
> how to avoid that situation in 1.6.x. These are some of my ideas, and
> ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
> release.
>
...
>
> Once 1.6.0-rc1 is released, I'll follow the standard soak process, with a final
> RC the week before release. Release Candidates should be just that: code which
> is ready for release, and which we'd feel perfectly comfortable releasing as the
> final release. Let's not have 11 "release candidates" before we find one we can
> actually release.
>
One way to avoid that is to have a clear view on when features are
ready. Given the clearly defined time box, I propose to define some
dates when certain checks and decisions can be made:
I'm thinking of:
- somewhere beginning October: look at the existing features and decide
what needs to be done to finish them for 1.6.
- mid October: fix the regressions introduced in trunk. A number of
tests have been marked as XFail on trunk in the last weeks (double
delete, tree conflicts). Some of them are due to changed behavior,
others due to regressions.
- continuously, end October at the latest: look at the test results of
the buildbots and make sure all tests pass on all tested platforms
(including serf). We could do with some more buildbots, especially for
bdb testing.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release Management for 1.6.x
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> Hello all,
>>
>> Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
>> how to avoid that situation in 1.6.x. These are some of my ideas, and
>> ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
>> release.
>>
>> Branching 1.6.x will happen sometime during the first couple weeks of November.
>> This is flexible, but we should try to be as close to that time frame as
>> possible. If features aren't quite ready for release by that time, we'll can
>> pull 'em and they can wait for 1.7. We already have enough new features to
>> justify a release by the end of the year.
>>
>> As soon as the branch happens, I'll roll 1.6.0-pre1.
>
> Does this imply that CHANGES will be up to date at this time? I ask because
> it would be a great help to the book maintainers if CHANGES was up-to-date
> ASAP so we can begin documenting the new release stream.
Ideally yes, but I don't think we should require CHANGES (as well as the release
notes, etc.) to be complete until the first RC. After all, if a tarball doesn't
have an appropriate CHANGES file, it isn't ready for release, and therefore
shouldn't be a release candidate.
But generally, I agree that the sooner we update CHANGES and the release notes,
the better.
-Hyrum
Re: Release Management for 1.6.x
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
> Hello all,
>
> Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
> how to avoid that situation in 1.6.x. These are some of my ideas, and
> ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
> release.
>
> Branching 1.6.x will happen sometime during the first couple weeks of November.
> This is flexible, but we should try to be as close to that time frame as
> possible. If features aren't quite ready for release by that time, we'll can
> pull 'em and they can wait for 1.7. We already have enough new features to
> justify a release by the end of the year.
>
> As soon as the branch happens, I'll roll 1.6.0-pre1.
Does this imply that CHANGES will be up to date at this time? I ask because
it would be a great help to the book maintainers if CHANGES was up-to-date
ASAP so we can begin documenting the new release stream.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Release Management for 1.6.x
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 17, 2008 at 12:12 PM, Jeremy Wilkins
<je...@ibexinternet.co.uk> wrote:
> Comments from a casual bystander
>
>> 1) We need to fix our process that leads up the RC so that test
>> results do not come as a surprise. Ideally we could make better use
>> of buildbot and have it do a complete test run on the branch on a
>> regular basis. But maybe there are other options. The -preN releases
>> are not going to help unless people are going to run all the tests.
>> Given that there is nothing stopping us from doing it without these
>> tarballs, I do not think releasing them is going to fix this. I still
>> think they are a good idea, they just are not going to fix this alone.
>
> In some ways this is related to the lack of precompiled binaries for RCs.
> Most svn users, particularly mac and windows, will only ever use binaries.
> Many of the users would quite happily test development copies of svn but a
> lack of binaries automatically closes out that entire user base to testing
> pre releases. Not understanding compiler tool chains doesn't automatically
> mean someone isn't technical enough to file a good bug report.
For 1.5, CollabNet provided binaries for Windows, OSX, Solaris and Red
Hat throughout the process. We even had Alpha and Beta releases where
binaries were provided. As Stefan pointed out, TortoiseSVN provides
binaries as well. And I will add that Subclipse did as well.
FWIW, and this might be directed at the reply from Stefan. I think we
did get some decent feedback from users, particularly via TortoiseSVN.
Though he raises some good points about things that could improve
testing quality. When I talked about community feedback, I was
thinking of consumers of our API, and especially those that are
consuming layers of the API that TortoiseSVN and other clients do not.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release Management for 1.6.x
Posted by Jeremy Wilkins <je...@ibexinternet.co.uk>.
>
Hi,
Comments from a casual bystander
> 1) We need to fix our process that leads up the RC so that test
> results do not come as a surprise. Ideally we could make better use
> of buildbot and have it do a complete test run on the branch on a
> regular basis. But maybe there are other options. The -preN releases
> are not going to help unless people are going to run all the tests.
> Given that there is nothing stopping us from doing it without these
> tarballs, I do not think releasing them is going to fix this. I still
> think they are a good idea, they just are not going to fix this alone.
In some ways this is related to the lack of precompiled binaries for
RCs. Most svn users, particularly mac and windows, will only ever use
binaries. Many of the users would quite happily test development
copies of svn but a lack of binaries automatically closes out that
entire user base to testing pre releases. Not understanding compiler
tool chains doesn't automatically mean someone isn't technical enough
to file a good bug report.
jebw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Release Management for 1.6.x
Posted by Stefan Küng <to...@gmail.com>.
Mark Phippard wrote:
> There were 11 release candidates. But 5 were never released because
> our own test suite failed and one had to be reissued two days later.
> In addition the last 4 release candidates came out within the last two
> weeks. This tells me a couple things:
>
> 1) We need to fix our process that leads up the RC so that test
> results do not come as a surprise. Ideally we could make better use
> of buildbot and have it do a complete test run on the branch on a
> regular basis. But maybe there are other options. The -preN releases
> are not going to help unless people are going to run all the tests.
> Given that there is nothing stopping us from doing it without these
> tarballs, I do not think releasing them is going to fix this. I still
> think they are a good idea, they just are not going to fix this alone.
>
> 2) We did not get any real community feedback until we were
> threatening to do the final release. I do not think there is much we
> can do about this, it is something that I think is just an unknown
> factor we always have to deal with. There are a lot of tools and
> scripts that use our libraries and we know our test suite is weak in
> this area. I expect this to be a continuing problem in future
> releases. That said, if our release process becomes more efficient,
> we may find that a lot of these things start getting reported and
> fixed in ".1" releases because we got the release out before community
> people started to really test it.
The TortoiseSVN nightly builds (trunk, not from the stable branch) are
always linked against the Subversion trunk (updated regularly, the
svn:externals are pulled in with -r specified to avoid build breakage).
There are a few people who download and use those. These people usually
update on a weekly basis (or sooner if they want to test a new feature
or check whether a bug they found might be fixed).
But even with those people using trunk, it's simply not possible to find
all issues. Especially features which they don't use regularly won't get
tested a lot.
With 1.5 the problem was for most of our testers that they couldn't test
against an 1.5 server. So merge tracking wasn't tested as well as we'd
hoped.
What also would help a lot is if there was an official test server
available - maybe with public write access, but the repo would get
purged every few hours automatically?
For example, the sasl authentication was hard to test because I couldn't
get a server working on my Windows machine. When users started to report
problems with it, I had no idea whether the issue was in the code or in
their setup - it we had a test server, I could just point them there: it
it works with the test server, it's their setup. If not, I know that
it's not a setup issue and can look in the code.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Release Management for 1.6.x
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 16, 2008 at 9:46 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Since the 1.5.x release process fiasco, I've been doing a lot of thinking about
> how to avoid that situation in 1.6.x. These are some of my ideas, and
> ultimately they form the basis of how I'm planning on proceeding with the 1.6.0
> release.
>
> Branching 1.6.x will happen sometime during the first couple weeks of November.
> This is flexible, but we should try to be as close to that time frame as
> possible. If features aren't quite ready for release by that time, we'll can
> pull 'em and they can wait for 1.7. We already have enough new features to
> justify a release by the end of the year.
>
> As soon as the branch happens, I'll roll 1.6.0-pre1. I'll continue with weekly
> -preX releases until there are no known issues, as which point I'll roll
> 1.6.0-rc1. If we don't have any known issues when we branch, I'll skip the
> -preX series. The purpose of the -preX series is to get code from the branch
> released soon and often, even if we are still working on stabilizing known
> issues. Hopefully your testing environments are well scripted by now. :)
>
> Once 1.6.0-rc1 is released, I'll follow the standard soak process, with a final
> RC the week before release. Release Candidates should be just that: code which
> is ready for release, and which we'd feel perfectly comfortable releasing as the
> final release. Let's not have 11 "release candidates" before we find one we can
> actually release.
>
> I don't think these ideas are radically different than we've previously done,
> just a little bit more formalized. Feedback is welcomed and encouraged.
I am +1 to the plan because I think getting the code out in people's
hands on a regular basis will be good. That said, I do not believe
these changes by themselves would do anything to change what happened
last time. Take a close look at what happened:
There were 11 release candidates. But 5 were never released because
our own test suite failed and one had to be reissued two days later.
In addition the last 4 release candidates came out within the last two
weeks. This tells me a couple things:
1) We need to fix our process that leads up the RC so that test
results do not come as a surprise. Ideally we could make better use
of buildbot and have it do a complete test run on the branch on a
regular basis. But maybe there are other options. The -preN releases
are not going to help unless people are going to run all the tests.
Given that there is nothing stopping us from doing it without these
tarballs, I do not think releasing them is going to fix this. I still
think they are a good idea, they just are not going to fix this alone.
2) We did not get any real community feedback until we were
threatening to do the final release. I do not think there is much we
can do about this, it is something that I think is just an unknown
factor we always have to deal with. There are a lot of tools and
scripts that use our libraries and we know our test suite is weak in
this area. I expect this to be a continuing problem in future
releases. That said, if our release process becomes more efficient,
we may find that a lot of these things start getting reported and
fixed in ".1" releases because we got the release out before community
people started to really test it.
With the exception of all the embarrassing failures to get the RC's
released, I do not think the cycle was as abnormal as people think.
There were essentially 3 RC cycles. The last cycle just had a lot of
bad timing as new API compatibility issues kept surfacing on the same
days we were doing a "final RC". With just different luck these could
easily have all come in together and gone out in one RC.
A product as widely used as SVN is never going to be released in one
RC, at least not unless our tests start covering a lot more of our
API. While I do not think we should plan to have multiple RC's, I
think we should still expect it is going to happen and not feel like
we failed if it does.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org