Subversion

Review of D&D 4th Edition

Posted 5 days ago by nob...@example.com (Ben Collins-Sussman)

Well friends, it’s time for my uber-geeky D&D post. I figure that if you
can bear listening to me blab about version control software, banjos, and
canned tuna… you can listen to my review of the new 4th Edition D&D
rulebooks that came ... [More] out this summer.

My affair with D&D has been on-and-off my whole life. I played 1st
edition in 2nd and 3rd grade, then lost interest. I somehow missed the
entire 2nd edition of the game completely. When the 3rd edition came out
in 2000, I had just gotten back into the game by playing in NASCRAG
touraments, so it was like learning the game all over. And now, eight
years later, it’s time for the owners-du-jour to do another round of tax
collection: everyone buy new books, relearn the rules.

As usual, the internet is full of people screaming about how the game has
been ruined and destroyed, how Wizards of the Coast is evil and greedy
and oppressing the freedom of gamers everywhere, forcing us into a
treadmill of upgrades. Just like what happened back in 2000. :-) This
time around, the biggest screams have been “OMG they dumbed it down into
a video game!” There’s a grain of truth to the accusation, but I decided
to give the new rules a good sincere try before condemning them. So I
invited some friends over. Everyone rolled up a character, and we did a
three-hour test game.

The verdict is: I really like 4th Edition. It was super fun. And everyone
who played was raving about it as well. We’re talking about continuing
the game now. The common quote was how somehow the new rules (with all
the “powers”) essentially made 1st-level combat feel like 5th level. No
more 1st-level magic users with 3 hit points and 11 AC expending a single
magic missile, then hiding in a closet until the next morning. Nope, the
1st level wizard was kicking ass just as much as the paladin, and having
a blast!

The new edition seems to be mainly a rewrite of combat rules, and done
such that combat is much much much more fun. Not less complex, but way
more entertaining. No more endless rounds of “I swing my sword for the
17th time” — it’s all about doing funky ‘powers’ each round, which keeps
things interesting. (The comparison to World of Warcraft is justified
here!) However, my players weren’t spacing out when it wasn’t their turn
— instead, they were on the edge of their seats to see what kind of crazy
stunts their allies were going to do. When was the last time you saw that
happen?

The other big change is that using a battlemat and miniatures is sort of
a requirement now. In 3rd edition, the board-game aspect was an optional
enhancement, one which made combat more visually accessible and
strategic. In 4th edition, many powers are described in terms of the grid
(”explodes in a radius-3 burst”), so it’s kind of hard to not have one
now. Maybe this doesn’t bug me, because I’ve always used a battlemat
anyway.

If anything is to be criticized, it’s the writing and artwork in the new
rulebooks. The art is cheap and cheesy looking. Imagine the worst fantasy
art you can, and then take it down a notch. It’s almost like the cover
paintings on bodice-ripping romance novels. And the writing is horrible
as well: a much bigger font, with writing style apparently targeting 9
year olds. I think it’s noble that the new owners want to indoctrinate a
“new generation” of roleplaying gamers, but in the process the books have
turned into what reads like a cartoonish self-mockery of the entire
genre. For example, here’s a lovely excerpt from the new Player’s
Handbook:

“Imagine a world of bold warriors, mighty wizards, and terrible
monsters [...] ancient ruins, vast caverns, and great wild wastes
where only the bravest heroes dare to tread. Imagine a world of
swords and magic, a world of elves and goblins, a world of giants and
dragons [...]”

Gag me with a spoon.

Ultimately, though, if you’re an experienced D&D player, this corny
writing doesn’t matter at all. There’s nothing stopping you from running
a dark campaign, creating characters of real depth and motives, and doing
serious roleplaying as you’ve always done. The only “new” thing here is
excitement of combat; the storytelling and improv acting hasn’t been
taken away.

As I was reading the rulebooks, I took notes as I went. You can read my
notes here which compare the old and new rules. I hope they’re useful to
people thinking of trying out the new edition!

I’m off to OSCON in Portland tomorrow, and Fitz and I are scheduled to
give four joint presentations. I’m sure I’ll have blog updates
forthcoming! [Less]

Log cache and repository UUIDs

Posted 8 days ago by nob...@example.com (steveking)

Fetching the log for slow or very big repositories can take quite a
while. And of course, it requires you to be connected to the repository.
You can't show the log messages if you're not online - very annoying if
the network is down or you're in a place where you don't even have
network access.

read more

Subversion 1.5 RPMs for 64-bit Linux

Posted 9 days ago by nob...@example.com (Mark Phippard)

We have had a lot of people request that we provide RPMs for 64-bit
Linux. As of today, you can now download those RPMs from our Subversion
"community" downloads section:

http://www.collab.net/downloads/community/

CollabNet ... [More] hosts two kinds of Subversion downloads. Our "CollabNet
Subversion" binaries and "Community" binaries. The CollabNet Subversion
binaries are built and certified by CollabNet and we provide commercial
support and SLA's for those binaries. The community binaries are
essentially binaries we have created but have not certified and we do not
provide any SLA for them. We certainly provide help in our discussion
forums and we have even made changes to the binaries in the past based on
comments we receive from the community.

We do intend to add 64-bit Linux support to our official CollabNet
Subversion binaries. We just are not ready to do so yet. Once we add a
package to CollabNet Subversion it falls under the SLA we provide our
customers, and so we cannot add a package until we are ready to provide
that level of support. In the case of 64-bit Linux we have to make sure
the necessary hardware is in place, in sufficient quantity, across all
areas of the company that need access to it in order to provide our SLA
to our customers.

CollabNet engineering has been preparing 64-bit RPMs since early in the
Subversion 1.5 development lifecycle, and we of course did so when 1.5.0
was released last month. With so many users requesting 64-bit binaries,
we have been looking for a way to deliver these RPMs to the users that
need them. The community download site gives us this opportunity, just as
it did when we wanted to provide the community with binaries for OSX.

The RPMs carry the branding of CollabNet Subversion and are identical in
packaging to our 32-bit RPMs. Again, this is because we are preparing for
the day when they will be added to our officially certified packages. If
you are experiencing any problems or difficulties with the packages,
please post to our discussion forum. [Less]

Subversion 1.5 RPMs for 64-bit Linux

Posted 9 days ago by Mark Phippard

Subversion merge reintegrate

Posted 12 days ago by nob...@example.com (Mark Phippard)

This post covers several topics related to merging with Subversion 1.5.
The goal is to explain the problem of reflective merges, how the new
reintegrate option helps, and also some problems that currently exist
with that ... [More] option.

Reflective/Cyclic Merges
------------------------

This is easiest to explain with an example. Suppose you are working on a
feature branch copied from your trunk. During the development process you
regularly merge ''all'' new changes from trunk to your branch so that the
branch stays in "synch" with the work occurring on trunk. When you
eventually merge your branch back to trunk, that is called a reflective
(or cyclic) merge. This type of merge is problematic for Subversion,
let's look at why.

Revisions and Merge Tracking
----------------------------

Subversion is based on revisions. Every commit to the repository creates
a new revision and a merge is ultimately just a commit. Subversion 1.5's
merge tracking feature is all about recording which revisions were merged
to which paths. In the previous reflective merge example, this is too
coarse of a solution to always yield the right results. Recall that in
our example we regularly merged changes from trunk to our branch. Each of
those merges winds up as a commit (revision) on our branch. When it comes
time to merge our branch back to trunk, all merge tracking can do is help
decide whether to include or exclude those "synched" revisions. The
problem is that neither answer is always right.

If we exclude the revisions that were merges from trunk, then we also
exclude any work we did to resolve conflicts as part of those merges.
Even worse, we might have carelessly committed unrelated changes as part
of the merge (it happens) so those changes would also be excluded.

If we include those synched revisions, then we merge back changes that
already exist in trunk. This yields unnecessary and confusing conflicts.

The only way to truly solve this is to invent a new merge algorithm in
Subversion that does not rely simply on revisions. In discussing the
problem it was suggested that this might require designing a new
repository format as well. As part of the 1.5 development cycle some
preliminary work was done to explore a new algorithm within our existing
design. Ultimately we decided a new algorithm was not in scope for this
release and to ship without it (the release cycle was long enough as is).
We hope to revisit this work for 1.6 or a future release to see if it
pans out as a solution.

Reintegrate to the Rescue
-------------------------

Setting aside the issue of new algorithms for a moment, it turns out
Subversion already has a technique that does the right thing with
reflective merges. It is the one we used prior to 1.5 and is called a
2-URL merge. Going back to our original example, suppose the last time we
merged trunk to our branch, we merged all the changes up to revision 100.
To properly merge our branch back to trunk, we start with a trunk working
copy and run this command:

svn merge url://trunk@100 url://feature-branch .

This tells Subversion to calculate the differences between trunk at r100
and the feature-branch at HEAD, and merge those differences into our
working copy. Since this is essentially just producing a diff, it
includes our conflict resolution work, and does not include any changes
that exist in both places. In other words, we get the result we want.

The new reintegrate option is a shorthanded version of the 2-URL merge.
With it you can just run this command:

svn merge --reintegrate url://feature-branch .

Internally, when you use this option, it calculates the url://trunk@100
part and then executes the EXACT SAME merge API that the 2-URL merge
does. This is important to remember when discussing some of the problems
with this new option, because you can generally use the old 2-URL syntax
to resolve the problem. In other words, reintegrate is just a new syntax
plus some safety checks (more on this later). If these checks fail and
cannot easily be corrected, then you can use the older syntax.

One big problem in general with the 2-URL merge process is that it will
do whatever you tell it. You can very easily make mistakes that the
command won't catch. Suppose we left off the @100 in our example and that
r101 and r102 were committed to trunk since we last synchronized with it.
When the 2-URL merge runs, it calculates the differences between
trunk@HEAD and branch@HEAD. To the merge process, it would look like the
branch removed the changes that happened in r101 and r102 and the merge
would remove them from your working copy! Depending on the change in
those revisions, you might not notice this and wind up committing the
removal of those changes as part of the merge. There are a lot of other
variations on this problem (such as getting the URL wrong), but most of
those problems are at least more obvious and you could just revert the
merge.

Because of this problem with the 2-URL merge process, when the
reintegrate option was added we decided it should do some safety checks
before it will run. Some of these are fairly tame, such as making sure
the working copy is at a single revision, with no switched children, and
is not a sparse checkout (i.e. working copy depth is infinity). If
reintegrate errors out because of any of these problems, you can
generally just use svn update or switch to "fix" your working copy. Since
reintegrate needs to calculate the base URL and revision for the merge,
it also does an ancestry check to ensure the merge source is related to
the merge target.

The most controversial reintegrate check is that the merge source does
not have any subtree mergeinfo. Mergeinfo (technically the versioned
property svn:mergeinfo) stores merge tracking information. Normally
mergeinfo is set only on the merge target. Subtree mergeinfo occurs when
a merge target has some subtree that was previously a merge target itself
(e.g. we merged from a file in trunk to a file in our branch, creating
mergeinfo on that file. This type of merge is fittingly called a subtree
merge). When reintegrating the branch back to trunk the reintegrate
safety checks fail because the branch has subtree mergeinfo. The reason
for this check is that a 2-URL merge in this situation doesn't always
give the right results.

Problems with Reintegrate and Renamed Files
-------------------------------------------

Most of the problems with reintegrate stem from this check for subtree
mergeinfo. When this check fails, the error you see on the command line
is something like this:

svn: Cannot reintegrate from 'url://feature-branch' yet:
Some revisions have been merged under it that have not been merged
into the reintegration target; merge them first, then retry.

The biggest problem is that, unlike when the other checks fail, both this
problem itself and the way out of it are less obvious. If you really did
some subtree merges then these checks save you from making a mistake.
Unfortunately there is a very common case people are running into where
it only ''appears'' like a subtree merge was performed: When you
rename/move something, mergeinfo is created on the new path and this
blocks reintegrate from working. The reasons why copy/move create
mergeinfo are beyond the scope of this post, but suffice it to say that
we think in the majority of cases the mergeinfo needn't be created. So
the fix we will look at (hopefully in time for 1.5.1) is to be smarter
about when copy/move creates mergeinfo. If those subcommands minimize
their creation of mergeinfo, then that would greatly reduce the
occurrence of this specific problem when using reintegrate (at least for
your future copy/move operations).

If you are running into this problem today, there are a couple of things
you can do.

1. You might want to just manually remove the subtree mergeinfo. You
can do this by running the command:

svn propdel svn:mergeinfo FOO

You could run this command after the move, and before you commit, so
that the problem never exists in the first place. Or it can be run
later to fix the problem after you realize you have it.

Generally, the only time mergeinfo needs to be created is when
copying/moving a path such that its nearest parent with mergeinfo is
different in the path's source and destination. This is because a
path without explicit mergeinfo (when a path has the svn:mergeinfo
property set on it it is said to have explicit mergeinfo) simply
inherits the mergeinfo of its nearest parent with explicit mergeinfo.
In other words, the svn:mergeinfo property is inheritable and if a
copied path inherits mergeinfo from the ''same'' place in both its
source and destination, then there is nothing gained by setting
explicit mergeinfo on the destination and you can safely delete that
mergeinfo.

In many cases, all mergeinfo exists on the root of your branch. If
you move a path within the branch, then its nearest parent with
mergeinfo (the root of the branch) does not change and the path does
not need new mergeinfo. If however, you previously did a subtree
merge and then move a path from outside the subtree into the subtree
(or vice-versa) then the path inherits different mergeinfo. In this
case the destination path should keep its explicit mergeinfo.

2. You can also use the old 2-URL merge syntax in this situation.

Additional Reintegrate Problems
-------------------------------

Closely related to the previous problem is when subtree mergeinfo is
merged into branches or carried into branches when the branch is created
(rather than being created in the branch as above). If you rename a path
in trunk (which currently creates mergeinfo), every branch you then
create from trunk from then onward also has this subtree mergeinfo.
Alternatively, if you copy trunk to a branch, then copy a path within
trunk (again creating mergeinfo), then synch up your branch, then the
branch get's subtree mergeinfo merged into it. In either case this
effectively means you can never use reintegrate, at least not unless you
can delete the svn:mergeinfo property from the subtree's that have it.

So in addition to being smarter about creating the mergeinfo, we need to
examine whether reintegrate can safely ignore subtree mergeinfo in some
cases and allow the reintegrate merge to proceed. For example, what if we
create a branch from trunk and some subtree mergeinfo comes into the
branch when it is created. As long as the subtree mergeinfo that exists
on the branch remains equivalent with what is in trunk, it's probably
safe to allow a reintegration merge. Of course these sorts of checks
start to get real complicated so we are less sure there are easy
solutions here, but hopefully there are some that might make their way
into 1.6. One solution that might be worth considering is whether we
ought to do this check in the first place?

Branch Management and Reintegrate
---------------------------------

An important thing to point out, and I am not sure if the documentation
currently does, is that once a branch is reintegrated, it should really
be deleted. If more work needs to happen, create it again with a fresh
copy. There are two reasons for this:

1. Remember our example with reflective merges? Once you merge your
branch to trunk, if you later want to synch all the changes with
trunk back to the branch, you are now in this same reflective merge
scenario with your branch! You can no longer use the simple "svn
merge url://trunk" syntax you were using previously so you have to
use 2-URL merges to get your trunk changes into your branch.

2. If you do not merge trunk changes back to your branch because of the
previous point, then when you go to reintegrate again, it will still
see r100 (to use our example), as the last trunk revision merged to
the branch. So when it diffs trunk@100 with your current branch, it
will not "see" that in r103 you merged the branch to trunk and it
will try to merge everything again.

The bottom line is that if you recreate your branches you will not run
into this. svn delete followed by svn copy runs fast, and does not take
up any repository disk space. You do not even have to do anything special
to your working copy. So just do it!

Future Solutions
----------------

This post has largely been focused on some problems we have been seeing
and were aware of when we released 1.5. I wanted to get this post out so
that we can aid users in understanding the root of the problems. That
said, I do not want to leave you with an impression of "doom and gloom".
The fact is that overall the new 1.5 merge process works quite well and
is a substantial improvement over previous versions. And while the
current reintegrate solution for reflective merges can only take us so
far without a new merge algorithm, if you understand the process, you can
develop a workflow that largely avoids the noted limitations. There are
also a few other other merge bugs we didn't cover here but fixes for
these are targeted for the the upcoming 1.5.1 release (which is
tentatively scheduled for release late this month).

It is also worth noting that now that merge tracking is "in the wild",
the development community has real world data and use cases to work with,
making it a lot easier to evaluate new algorithms and bug fixes. This
should help us get fixes out on the 1.5.x line more quickly. The lack of
large, real world repositories using merge tracking was a problem during
the development of 1.5.0 as those simply did not exist (outside of
Subversion's own repository).

Finally, I just want to point out that I have turned off comments on this
post. I suspect this post will raise a number of questions and I'd just
prefer to handle these in a proper discussion forum. I have created a
thread to post comments and questions related to this post in the
Subversion forum on openCollabNet. Please post your comments and
questions to that thread. [Less]

Subversion merge reintegrate

Posted 12 days ago by Mark Phippard

Text Adventures on the iPhone… or not.

Posted 14 days ago by nob...@example.com (Ben Collins-Sussman)

As many folks know, I’m a huge fan of Interactive Fiction (text
adventures). I’ve been working on a z-machine interpreter for Android, as
well one that runs in python.

As of today, my iPhone is able to download ‘legitimate’ ... [More] apps from the
AppStore, and there’s still no z-machine interpreter available. For over
a year now, there’s been one which requires a jailbroken iPhone out
there, but jailbreaking isn’t an option for me (since Google owns my
phone.)

My hopes got up when I discovered that the author of Zoom (the best
z-machine app for Mac OS X) is actively working on a legitimate iPhone
port. However, something he posted really disturbs me:

“A more serious issue is that Apple’s SDK license prohibits
downloading code to interpret: this means that it would be impossible
to load any games that were not bundled with the interpreter. I think
this is probably a fatal problem: it seems doubtful that many IF
authors will be willing to pay the $99 required to get their work
onto the iPhone - plus it would mean no Zork, ever.”

While it sure is convenient that iPhone users only have one place to
check for apps, this really scares me. I’m guessing that the license is
intended to prevent people from distributing generic JVM or CLR machines
that can download and run any old code, thereby circumventing Apple’s
ability to vet applications. But clearly their Safari web browser already
downloads and interprets Javascript apps, right? Where does one draw the
line? We’re talking about a VM to play text-adventures — would Apple
consider the fetching of text-adventures dangerous?

More and more, it’s clear to me that Apple is just as evil as Microsoft,
they’re just not as big and powerful (yet)… and they have better taste.
Maybe I should give up on issue and just wait for my Android phone at the
end of the year. It will be a truly open OS, and I’ll be able to download
and run whatever the heck I want. [Less]

AnkhSVN 2.0 Final Released

Posted 16 days ago by nob...@example.com (Jeremy Whitlock)

Well, AnkhSVN 2.0 officially began last November when the original team
of AnkhSVN developers and CollabNet got together to jointly develop the
next iteration. The purpose of CollabNet's involvement was to provide
some commercial backing ... [More] to help solidify development resources and to
help invigorate the community around AnkhSVN. In fact, the Microsoft open
source folks are involved with the project as well providing free MSVS
licenses for the developers, a tech support contact, roadmap discussions
with customers, and co-marketing activities that you'll see in the near
future, like webinars. (Sam Ramji, Sr. Director of Platform Strategy at
MS, talked about this at EclipseCon.) The fruits of the venture are
finally available with AnkhSVN 2.0.

AnkhSVN 2.0 is a near rewrite of the original AnkhSVN. If you look at the
AnkhSVN 2.0 Roadmap you'll see that the whole delivery mechanism of
AnkhSVN was changed from a Visual Studio Add-In to a full Source Control
Provider Integation Package. (This means no more home-grown SCM layer
maintained by AnkhSVN. AnkhSVN now hooks into the VisualStudio.NET SCC
APIs to provide much better integration and performance.) AnkhSVN also
adds Subversion 1.5 support by using SharpSvn as the underlying
Subversion client API. While those two architectural changes don't do
much for adding new features, other than Subversion 1.5 support, what
does AnkhSVN 2.0 bring to the table? Well, below is a short list of what
is new in AnkhSVN:

* Pending changes window; subversion status and commands available in
one place

* Full support for Visual Studio 2005 and 2008; AnkhSVN is now a SCC
package instead of just an addin

* Better log viewer

* Merge support

* Property editor

* AnkhSVN now supports most project types previously unsupported via
the SCC api

* All solution explorer actions (rename, copy&paste, drag&drop) keep
subversion history now

* Enhanced build process and setup

* Automatic check for updates

* And last but certainly not least end user documentation

The list above is not complete, nor does it fully explain the benefits of
AnkhSVN 2.0. Expect to see huge performance increases above AnkhSVN 1.x,
better badging/glyphs, more tools and a more complete Subversion client
interface. For more information on AnkhSVN and its 2.0 release, please
use the following resources:

* AnkhSVN Homepage

* AnkhSVN 2.0 Roadmap

* AnkhSVN 2.0 Screenshots

* AnkhSVN 2.0 Online Documentation

* AnkhSVN 2.0 Download

AnkhSVN 2.0 is a major improvement in the AnkhSVN line. Expect to see
more new features in the near future and as always, AnkhSVN is an open
source project so feel free to contact us to report bugs, suggest new
features or to provide any other feedback. [Less]

AnkhSVN 2.0 Final Released

Posted 16 days ago by Jeremy Whitlock

StExBar and SkTimeStamp for x64

Posted 17 days ago by nob...@example.com (steveking)

Both the StExBar and the SkTimeStamp extensions are now available for x64
OS. So if you're using a 64-bit Windows, grab the new versions!

If you're using a 32-bit Windows, you should also get the new versions
because I fixed some small bugs there too.

read more

What I Did on my Summer Vacation

Posted 19 days ago by nob...@example.com (Ben Collins-Sussman)

I’m done with a nice 12-day vacation. I was definitely on the verge of
burning out; unproductive at the office and cranky at home all the time.
I really needed to step back and forget about computers for a while.

What I did ... [More] instead:

* Went on a family vacation to Dubuque, Iowa, a mere 3 hour drive from
Chicago.

* Stayed in a hotel-waterpark with wife and 2 year old. Waterpark
every day.

* Horse-carriage rides.

* Mississippi paddleboat rides.

* Mississippi Aquarium Museum.

* Lots of ice cream.

* Finally finished reading Watership Down.

* Started reading The Compassionate Carnivore, which gives me a warm
fuzzy feeling that I’m not alone in being a freerange-itarian.

* Read the through the new 4th edition D&D Player’s Handbook. I’m a
geek. I like roleplaying games. Sue me.

* Went to the Indiana Dunes — at a friend’s house — for the 4th of
July.

* Went to the Bristol Renaissance Faire

* Shot 300 photos. A few of them were pretty good.

* Beta-tested an excellent new text-adventure game written by a friend;
it should be available to the public by August 1st.

* Played my banjo at the usual Friday night jam.

Time to go back to Google; I’m continuing to lead a team whose goal is to
make Google Code’s Subversion service as fast and scalable as possible. [Less]

Adventure Aborted

Posted 25 days ago by nob...@example.com (Hyrum)

Packed and ready to goSince moving from Utah almost 2 years ago, I’ve
been aching to get back into the mountains for a few days. Our previous
attempt as a family notwithstanding, I’ve been looking forward to a
chance for some serious ... [More] mountain hiking and backpacking for a while.
Rooming with Bruce this summer has been fortuitous in that we both enjoy
the outdoors, having done a few hikes while living together previously as
roommates at BYU.

The Plan was to spend this entire week in the Trinity Alps Wilderness in
Northern California. (In spite of what people in the Bay Area will say,
there really is a substantial part of California farther to the north.)
The Trinity Alps are part of a relatively-unknown area which contains
large amounts of virgin timber and several dozen high alpine lakes, the
perfect place to disappear from civilization for a week.

Unfortunately, we managed to pick the weekend when the entire state of
California turned into a giant campfire. With packs loaded and ready to
go, we drove over 12 hours during the course of a 24-hour period, looking
for a place to go backpacking, from Oregon to Yosemite, but to no avail.
I refer the interested reader to Bruce’s fascinating writeup and analysis
for more information, but suffice it to say I’m spending the evening
writing this post instead of counting the stars in the Milky Way. Bummer. [Less]

Home Owners

Posted 25 days ago by nob...@example.com (Garrett Rooney)

Well, as of this morning Joanna and I are now officially home owners.
After far too much stressing over the last few months about obtaining a
mortgage and getting appraisals and whatnot we finally closed on our
house. We signed and ... [More] initialed a ridiculous number of forms ("Here, this
one is in triplicate, please initial all 15 pages and sign and date at
the bottom of page 14"), and handed over the largest check I've ever
held, but it's done and we're extremely happy about it.

It's a little weird, we've been living here since November so we don't
have the traditional "get the keys at the closing and run over to unlock
the door and go into your house for the first time" kind of experience.
On the bright side, we don't actually have to move anything in, which is
always nice ;-) [Less]

Cycling

Posted 27 days ago by nob...@example.com (Hyrum)

Bike and meWhile I’ve been in California this summer, I’ve been pretty
car-less and with gas prices the way that they are, I’m not complaining.
Instead of a car, I have a new bike, a Trek 2.3. I have wanted a road
bike for a long ... [More] time, and this summer turned out to be a opportune time
to get one.

Of course, I decided to go ahead and register for the Marin Century, even
though I hadn’t done any regular riding for the last two years. My daily
commute is around 7 miles, round trip, which gives me a chance to do push
myself, but I really enjoy the longer rides as well. This morning, I
decided to go for a 65-mile jaunt around the South Bay: over Dumbarton
Bridge, out through Newark and Milpitas, down around San Jose and back
through Cupertino and Los Altos. There weren’t any major climbs, but it
turned out to be quite the ride, and has given me some confidence for
riding a century only 5 weeks hence.

On an unfortunate note, I did forget the sunscreen today, so I’m sporting
some rather odd burn lines. [Less]

TortoiseSVN 1.5.0 released

Posted about 1 month ago by nob...@example.com (steveking)

We're proud to announce the release of TortoiseSVN 1.5.0, linked against
Subversion 1.5.0.

It's been almost two years (645 days to be exact) since we released the
last major version 1.4.0, and 5815 changes

read more

Tomatoes and Drunk Drivers

Posted about 1 month ago by nob...@example.com (Hyrum)

The CDC has reported that since April, 552 persons infected with
Salmonella Saintpaul. As a nation, our reaction has been almost heroic.
We’ve pulled tomatoes from store shelves and fast food restaurants,
banished them from sandwiches ... [More] and let tons of stock spoil. In spite of
its long-known and far-reaching health benefits, the tomato has overnight
become the worst villain in the culinary industry. (Fortunately for our
family, home grown tomatoes are still considered safe—for now.)

In 2006, the last year for which numbers are available, an estimated
17,602 people died in alcohol-related traffic accidents. In 2001, more
than half a million people were injured in crashes where police reported
that alcohol was present (source). That’s one injury every minute of
every hour of every day for the entire year. For those keeping score at
home, that one Salmonella case for every 208 alcohol-related injuries,
just since April.

Although know known deaths have occurred due to the Salmonella Saintpaul
outbreak, we’ve bent over backwards to “fix” that problem, but whatever
efforts we make to curb drunk driving seem to have little effect. Putting
my personal religious disdain of alcohol aside, it would just seem
sensible to put the same vigor into the problem of drunk driving as we do
to contaminated tomatoes. We seem to accept drunk driving and the
consequent deaths as an unfortunate part of life, whereas we have a right
to eat tomatoes risk-free. Maybe it’s just me, but this seems a bit
backward. I guess it just shows that the rational man is still an elusive
creature.

As Joseph Stalin once remarked, “A single death is a tragedy; a million
deaths is a statistic”. And that smells of rotten tomatoes. [Less]

CollabNet Subversion 1.5.0 binaries available

Posted about 1 month ago by nob...@example.com (Mark Phippard)

The first set of our binaries for CollabNet Subversion is now available.
Specifically, the RPM's for Red Hat Enterprise Linux. You can get them
here:

http://www.collab.net/downloads/subversion/redhat.html

These are certified ... [More] to run on all 32-bit versions of RHEL 4 and 5. In my
experience, they run fine on any version of Linux that allows you to
install an RPM. I have even used them successfully on Ubuntu and Debian
by using the alien package, which allows RPM to be installed on Debian
systems.

Starting with this release of CollabNet Subversion, our Linux RPM's are
now signed. You can (and should) download and import the GPG key they
were signed with. This was something several of our customers had asked
for. See the readme for the Linux binaries for details and instructions.

As I mentioned in yesterday's post, we plan to have the Windows binaries
available next week. Currently it looks like they should be available
sometime on Monday. The Solaris binaries will be posted around the end of
the week.

We are pretty excited about this release of the binaries. We put a lot of
effort into improving them and what we include in the packaging. Here are
some highlights:

* Standardized set of dependencies across platforms. Apache 2.2.8, APR
1.2.12, Neon 0.28.2. Our Windows binaries initially went out with
Apache 2.0 so we wanted to wait for Subversion 1.5.0 to make the
switch. There are upgrade considerations in moving from Apache 2.0 to
2.2 that Windows users will have to consider.

* ViewVC included! This is the biggest feature. Not only do we include
ViewVC 1.0.5, but we configure it for you automatically (if you ask
us to). It has never been easier to integrate this excellent tool
into your environment.

* Python bindings are included. These are needed for ViewVC, but also
allow you to use hook scripts that require the bindings, such as the
commit email hook script.

* JavaHL bindings are included with the client. This makes it easier
than ever to use JavaHL on all supported platforms, which means it is
also easy to use the CollabNet Desktop and our exciting new Merge
Client.

* SASL support is included in the client and server. This is a new
feature in 1.5. There is not a lot of information out there on how to
build and include it. We have figured it out though, and include it
in our package.

* We package the svn-populate-node-origins-index program so that you
have the tools you need to migrate existing repositories to
Subversion 1.5.

* As always, we provide packages using the native packaging format for
each operating system.

These are the main enhancements I can think of, but we have been working
on these improvements throughout the Subversion 1.5 life-cycle. Those of
you that participated in our Beta program have likely already experienced
some of these new features and seen the packages evolve over the life of
the program. Probably the biggest benefit of our packages is that we test
and certify the entire stack that we provide to you. We do this so that
we can provide the level of support that our customers ask for and so
that we can be confident that we can deliver on the SLA that we provide
to our customers.

Anyway, look for those Windows and Solaris binaries next week. Also, stay
tuned for some additional major new enhancements we will make to the
packaging over the course of the summer. That is all I will say for now,
but details will be coming out as we roll out these enhancements. [Less]

CollabNet Subversion 1.5.0 binaries available

Posted about 1 month ago by Mark Phippard

XP SP3 and date functions

Posted about 1 month ago by nob...@example.com (steveking)

During the last few weeks, I got a lot of crash reports for TortoiseSVN
which indicated that a certain date API returned bogus data, which either
lead to a crash (hence the crash reports) or garbled date strings in
various TortoiseSVN dialogs (these were reported on our mailing lists).

read more

Subversion 1.5.0 released

Posted about 1 month ago by nob...@example.com (Ben Collins-Sussman)

No, really. Seriously!

After nearly two years of work, it’s been released to the public.
Semi-intelligent tracking of merges, sparse directories, interactive
conflict resolution, and much much more all described here. I ... [More] had
previously posted about how easy it is to manage feature branches; now
you can try it yourself.

Visit subversion.tigris.org to download. (It make take a few days for
volunteers to update binary packages from the source code.) Also, we’ve
just about finished up the new edition of the Subversion Book, which now
covers 1.5. You can read it online, or wait a couple of months to buy a
hardcopy from O’Reilly. [Less]

Subversion 1.5.0 Released!

Posted about 1 month ago by nob...@example.com (Mark Phippard)

I am pleased to announce that Subversion 1.5.0 was released today. It has
been a long journey to get to this point, but I think the final result
will be worth it. Subversion 1.5.0 is the biggest release since 1.0 and
begins a new chapter ... [More] in the project's evolution. An event this big
probably calls for some profound comments and reflection. Perhaps, I or
others, will make some at some point in the future. Unfortunately, for
myself, and a lot of people at CollabNet, the release means a lot of work
and activity.

We have put together a page with links to lots of resources and
information about the release:

http://www.collab.net/products/subversion/subversion15.html

I'd particularly urge you to checkout the training materials that have
been created for this release. While Subversion 1.5 is compatible with
older clients and servers, to take full advantage of all the features,
particularly merge tracking, there are some steps you need to take. The
training courses we have created cover these issues and can help guide
you through the upgrade process.

Probably the number one thing people are looking for is binaries. I
assure you they are coming. CollabNet's binaries are certified and that
process cannot begin until the official release is made. So our team is
hard at work building and certifying the binaries. The tentative
certification schedule is:

Linux: June 20
Windows: June 24
Solaris: June 26

There is a pretty good chance that the Windows client will be available
sooner. I will add a new blog post once the Windows binaries are posted.
BTW, the OSX binaries are ready and just waiting for the web site to be
updated. Those binaries are not certified so can be released sooner. A
lot of us at CollabNet, myself included, use them for our daily work
though. [Less]

Subversion 1.5.0 Released!

Posted about 1 month ago by Mark Phippard

Programmer Insecurity

Posted about 1 month ago by nob...@example.com (Ben Collins-Sussman)

I’ve got a lot to say today!

I want to chat about something that I’ve never noticed before, but
probably should have. There’s always been a stereotype out there of
programmers being nerdy, anti-social people (Q: How do you know ... [More] when an
engineer is outgoing? A: He looks at your shoes!). But my revelation of
the week is that most programmers seem to be really insecure about their
work. I mean: really, really insecure.

My buddy Fitz and I have long preached about best practices in open
source software development — how one should be open and transparent with
one’s work, accept code reviews, give constructive criticism, and
generally communicate as actively as possible with peers. One of the main
community “anti-patterns” we’ve talked about is people writing “code
bombs”. That is, what do you do when somebody shows up to an open source
project with a gigantic new feature that took months to write? Who has
the time to review thousands of lines of code? What if there was a bad
design decision made early in the process — does it even make sense to
point it out? Dropping code-bombs on communities is rarely good for the
project: the team is either forced to reject it outright, or accept it
and deal with a giant opaque blob that is hard to understand, change, or
maintain. It moves the project decidedly in one direction without much
discussion or consensus.

And yet over and over, I’m gathering stories that point to the fact that
programmers do not want to write code out in the open. Programmers don’t
want their peers to see mistakes or failures. They want to work
privately, in a cave, then spring “perfect” code on their community, as
if no mistakes had ever been made. I don’t think it’s hubris so much as
fear of embarrassment. Rather than think of programming as an inherently
social activity, most coders seem to treat it as an arena for personal
heroics, and will do anything to protect that myth. They’re fine with
sharing code, as long as they present themselves as infallible, it seems.
Maybe it’s just human nature.

Check out some of these stories I’ve collected:

* Requests at the Google I/O booth: A couple of weeks ago when my team
was at the Google I/O conference, we ran a booth demonstrating our
Open Source Project Hosting service. Over and over, we kept getting
requests like this:

“Can you guys please give subversion on Google Code the ability
to hide specific branches?”

“Can you guys make it possible to create open source projects
that start out hidden to the world, then get ‘revealed’ when
they’re ready?”

Translation: “I don’t want people to see my work-in-progress until
it’s perfect.”

* Requests on the Google Code mailing list: Sometimes users need their
googlecode.com svn repositories wiped clean. Legitimate reasons
include the accidental commit of sensitive data, or the need to load
code history in from a different svn repository. But most of the time
we get (invalid) requests like this:

“Hi, I want to rewrite all my code from scratch, can you please
wipe all the history?”

Translation: “I don’t want people to be able to find my old code,
it’s too embarrassing.” Call it vanity, call it insecurity… the
bottom line is that coders want prior mistakes or failures to be
erased from history.

* Code-reviews taken as personal attacks. Fitz tells a funny anecdote
about a friend of his who went from the open source world to a
corporate software job. Vastly paraphrased:

During his first week, he started emailing friendly code reviews
to each of his coworkers, receiving strange stares in turn.
Eventually his boss called him into his office:

“You know, you really need to stop with the negative energy. Your
peers say that you’re constantly criticizing everything they do.”

Moral: not only is code review not the norm in corporate
environments, most programmers are unable to separate their fragile
egos from the code they write. Repeat after me: you are not your
code!

* Distributed version control — in a cave. A friend of mine works on
several projects that use git or mercurial. He gave me this story
recently. Basically, he was working with two groups on a project. One
group published changes frequently…

“…and as a result, I was able to review consistently throughout
the semester, offering design tweaks and code reviews regularly.
And as a result of that, [their work] is now in the mainline, and
mostly functional. The other group [...] I haven’t heard a peep
out of for 5 months. Despite many emails and IRC conversations
inviting them to discuss their design and publish changes
regularly, there is not a single line of code anywhere that I can
see it. [...] Last weekend, one of them walked up to me with a
bug [...] and I finally got to see the code to help them debug. I
failed, because there are about 5000 lines of crappy code, and
just reading through a single file I pointed out two or three
major design flaws and a dozen wonky implementation issues. I had
admonished them many times during these 5 months to publish their
changes, so that we (the others) could take a look and offer
feedback… but each time met with stony silence. I don’t know if
they were afraid to publish it, or just don’t care. But either
way, given the code I’ve seen, the net result is 5 wasted
months.”

Before you scream; yes yes, I know that the potential for cave-hiding
and writing code bombs is also possible with a centralized version
control system like Subversion. But my friend has an interesting
point:

“I think this failure is at least partially due to the fact that
[DVCS] makes it so damn easy to wall yourself into a cave. Had we
been using svn, I think the barrier to caving would have been too
high, and I’d have seen the code.”

In other words, yes, this was fundamentally a social problem. A team
was embarrassed to share code. But because they were using
distributed version control, it gave them a sense of false security.
“See, we’re committing changes to our repository every day… making
progress!” If they had been using Subversion, it’s much less likely
they would have sat on a 5000 line patch in their working copy for 5
months; they would have had to share the work much earlier. Moral:
even though one shouldn’t depend on technical solutions to social
problems, default tool behaviors matter a lot. This was my main theme
way back when I wrote about the risks of distributed version control.

OK, so what’s the conclusion here? People are scared of sharing their
unfinished work, plain and simple. I know this isn’t headline news to
most people, but I really think I’ve been in deep denial about this. I’m
so used to throwing my creative output up for constant criticism, that I
simply expect everyone else to do it as well. I think of it as the norm,
and I can’t comprehend why someone wouldn’t want to do that… and yet
clearly, the growing popularity of distributed version control shows just
how thrilled people are to hide their work from each other. It’s the
classic “testimonial” for systems like git (taken from a blog comment):

“Don’t tell me I should cooperate with other people at the beginning
and publish my modification as early as possible. I do cooperate with
other people but I do want to do some work alone sometimes.”

Hm, okay. Please just don’t work alone for too long!

Sidetracking a wee bit, I think this is why I prefer Mercurial over Git,
having done a bit of research and reading on both systems. Git leans much
more heavily towards cave-hiding, and I don’t like that. For example, the
‘git rebase’ command is a way of effectively destroying an entire line of
history: very powerful, sure, but it’s also a way of erasing your tracks.
Rather than being forced to merge your branch into a parent line, just
pretend that your branch was always based on the latest parent line!
Another example: when it comes to pushing and pulling changesets,
Mercurial’s default behavior is to exchange all history with the remote
repository, while git’s default behavior is to only push or pull a single
branch — presumably one that the user has deemed fit for sharing with the
public. In other words, git defaults to all work being private cave-work,
and is happy to destroy history. Mercurial shares everything by default,
and cannot erase history.

I know this post has been long, but let me stand on my soapbox for a
moment.

Be transparent. Share your work constantly. Solicit feedback. Appreciate
critiques. Let other people point out your mistakes. You are not your
code. Do not be afraid of day-to-day failures — learn from them. (As they
say at Google, “don’t run from failure — fail often, fail quickly, and
learn.”) Cherish your history, both the successes and mistakes. All of
these behaviors are the way to get better at programming. If you don’t
follow them, you’re cheating your own personal development.

Phew, I feel better now. [Less]

Programmer Insecurity

Posted about 1 month ago by nob...@example.com (Ben Collins-Sussman)

I’ve got a lot to say today!

I want to chat about something that I’ve never noticed before, but
probably should have. There’s always been a stereotype out there of
programmers being nerdy, anti-social people (Q: How do you know ... [More] when an
engineer is outgoing? A: He looks at your shoes!). But my revelation of
the week is that most programmers seem to be really insecure about their
work. I mean: really, really insecure.

My buddy Fitz and I have long preached about best practices in open
source software development — how one should be open and transparent with
one’s work, accept code reviews, give constructive criticism, and
generally communicate as actively as possible with peers. One of the main
community “anti-patterns” we’ve talked about is people writing “code
bombs”. That is, what do you do when somebody shows up to an open source
project with a gigantic new feature that took months to write? Who has
the time to review thousands of lines of code? What if there was a bad
design decision made early in the process — does it even make sense to
point it out? Dropping code-bombs on communities is rarely good for the
project: the team is either forced to reject it outright, or accept it
and deal with a giant opaque blob that is hard to understand, change, or
maintain. It moves the project decidedly in one direction without much
discussion or consensus.

And yet over and over, I’m gathering stories that point to the fact that
programmers do not want to write code out in the open. Programmers don’t
want their peers to see mistakes or failures. They want to work
privately, in a cave, then spring “perfect” code on their community, as
if no mistakes had ever been made. I don’t think it’s hubris so much as
fear of embarrassment. Rather than think of programming as an inherently
social activity, most coders seem to treat it as an arena for personal
heroics, and will do anything to protect that myth. They’re fine with
sharing code, as long as they present themselves as infallible, it seems.
Maybe it’s just human nature.

Check out some of these stories I’ve collected:

* Requests at the Google I/O booth: A couple of weeks ago when my team
was at the Google I/O conference, we ran a booth demonstrating our
Open Source Project Hosting service. Over and over, we kept getting
requests like this:

“Can you guys please give subversion on Google Code the ability
to hide specific branches?”

“Can you guys make it possible to create open source projects
that start out hidden to the world, then get ‘revealed’ when
they’re ready?”

Translation: “I don’t want people to see my work-in-progress until
it’s perfect.”

* Requests on the Google Code mailing list: Sometimes users need their
googlecode.com svn repositories wiped clean. Legitimate reasons
include the accidental commit of sensitive data, or the need to load
code history in from a different svn repository. But most of the time
we get (invalid) requests like this:

“Hi, I want to rewrite all my code from scratch, can you please
wipe all the history?”

Translation: “I don’t want people to be able to find my old code,
it’s too embarrassing.” Call it vanity, call it insecurity… the
bottom line is that coders want prior mistakes or failures to be
erased from history.

* Code-reviews taken as personal attacks. Fitz tells a funny anecdote
about a friend of his who went from the open source world to a
corporate software job. Vastly paraphrased:

During his first week, he started emailing friendly code reviews
to each of his coworkers, receiving strange stares in turn.
Eventually his boss called him into his office:

“You know, you really need to stop with the negative energy. Your
peers say that you’re constantly criticizing everything they do.”

Moral: not only is code review not the norm in corporate
environments, most programmers are unable to separate their fragile
egos from the code they write. Repeat after me: you are not your
code!

* Distributed version control — in a cave. A friend of mine works on
several projects that use git or mercurial. He gave me this story
recently. Basically, he was working with two groups on a project. One
group published changes frequently…

“…and as a result, I was able to review consistently throughout
the semester, offering design tweaks and code reviews regularly.
And as a result of that, [their work] is now in the mainline, and
mostly functional. The other group [...] I haven’t heard a peep
out of for 5 months. Despite many emails and IRC conversations
inviting them to discuss their design and publish changes
regularly, there is not a single line of code anywhere that I can
see it. [...] Last weekend, one of them walked up to me with a
bug [...] and I finally got to see the code to help them debug. I
failed, because there are about 5000 lines of crappy code, and
just reading through a single file I pointed out two or three
major design flaws and a dozen wonky implementation issues. I had
admonished them many times during these 5 months to publish their
changes, so that we (the others) could take a look and offer
feedback… but each time met with stony silence. I don’t know if
they were afraid to publish it, or just don’t care. But either
way, given the code I’ve seen, the net result is 5 wasted
months.”

Before you scream; yes yes, I know that the potential for cave-hiding
and writing code bombs is also possible with a centralized version
control system like Subversion. But my friend has an interesting
point:

“I think this failure is at least partially due to the fact that
[DVCS] makes it so damn easy to wall yourself into a cave. Had we
been using svn, I think the barrier to caving would have been too
high, and I’d have seen the code.”

In other words, yes, this was fundamentally a social problem. A team
was embarrassed to share code. But because they were using
distributed version control, it gave them a sense of false security.
“See, we’re committing changes to our repository every day… making
progress!” If they had been using Subversion, it’s much less likely
they would have sat on a 5000 line patch in their working copy for 5
months; they would have had to share the work much earlier. Moral:
even though one shouldn’t depend on technical solutions to social
problems, default tool behaviors matter a lot. This was my main theme
way back when I wrote about the risks of distributed version control.

OK, so what’s the conclusion here? People are scared of sharing their
unfinished work, plain and simple. I know this isn’t headline news to
most people, but I really think I’ve been in deep denial about this. I’m
so used to throwing my creative output up for constant criticism, that I
simply expect everyone else to do it as well. I think of it as the norm,
and I can’t comprehend why someone wouldn’t want to do that… and yet
clearly, the growing popularity of distributed version control shows just
how thrilled people are to hide their work from each other. It’s the
classic “testimonial” for systems like git (taken from a blog comment):

“Don’t tell me I should cooperate with other people at the beginning
and publish my modification as early as possible. I do cooperate with
other people but I do want to do some work alone sometimes.”

Hm, okay. Please just don’t work alone for too long!

Sidetracking a wee bit, I think this is why I prefer Mercurial over Git,
having done a bit of research and reading on both systems. Git leans much
more heavily towards cave-hiding, and I don’t like that. For example, the
‘git rebase’ command is a way of effectively destroying an entire line of
history: very powerful, sure, but it’s also a way of erasing your tracks.
Rather than being forced to merge your branch into a parent line, just
pretend that your branch was always based on the latest parent line!
Another example: when it comes to pushing and pulling changesets,
Mercurial’s default behavior is to exchange all history with the remote
repository, while git’s default behavior is to only push or pull a single
branch — presumably one that the user has deemed fit for sharing with the
public. In other words, git defaults to all work being private cave-work,
and is happy to destroy history. Mercurial shares everything by default,
and cannot erase history.

I know this post has been long, but let me stand on my soapbox for a
moment.

Be transparent. Share your work constantly. Solicit feedback. Appreciate
critiques. Let other people point out your mistakes. You are not your
code. Do not be afraid of day-to-day failures — learn from them. (As they
say at Google, “don’t run from failure — fail often, fail quickly, and
learn.”) Cherish your history, both the successes and mistakes. All of
these behaviors are the way to get better at programming. If you don’t
follow them, you’re cheating your own personal development.

Phew, I feel better now. [Less]

Subversion 1.5 - Release Candidate 9 Available

Posted about 1 month ago by nob...@example.com (Guido Haarmans)

Binaries of Subversion 1.5 - Release Candidate 9 are posted. As I wrote
last week, this Release Candidate does not reset the soak period. An API
issue was already discovered in RC9 and RC10 will likely come later this
week. RC10 won't ... [More] reset the soak period either, so we are still looking at
a likely Subversion 1.5 release next week. As always: unless a
showstopper is found.

If you are a regular reader of this blog, you know the drill: please
download the binaries and test the latest Subversion 1.5 Release
Candidate. You can ask questions and report issues in our forum. [Less]

Subversion 1.5 - Release Candidate 9 Available

Posted about 1 month ago by Guido Haarmans

Subversion 1.5 - Release Candidate 9 Available

Posted about 1 month ago by nob...@example.com (Guido Haarmans)

Binaries of Subversion 1.5 - Release Candidate 9 are posted. As I wrote
last week, this Release Candidate does not reset the soak period. An API
issue was already discovered in RC9 and RC10 will likely come later this
week. RC10 won't ... [More] reset the soak period either, so we are still looking at
a likely Subversion 1.5 release next week. As always: unless a
showstopper is found.

If you are a regular reader of this blog, you know the drill: please
download the binaries and test the latest Subversion 1.5 Release
Candidate. You can ask questions and report issues in our forum. [Less]

TortoiseSVN 1.5.0-RC3 released

Posted about 1 month ago by nob...@example.com (steveking)

We've created the third (and most likely last) release candidate of the
upcoming 1.5.0 release. We like to have as many people as possible to
give this release candidate a test and report back any bugs you find.

Note:

read more

Subversion Release Candidate 8 Posted

Posted about 1 month ago by nob...@example.com (Guido Haarmans)

This morning we posted binaries of the Subversion 1.5 Release Candidate 8
(RC8). Compared to RC7 this release candidate contains a few translation
updates and an API compatibility fix that does not affect the ... [More] command
line.

Another release candidate with minor changes might come. Yesterday RC9
was proposed (based on build r31577). RC9 fixes a potential issue in the
working copy when you checkout with the new –-depth feature. RC9 is “out
for signatures,” meaning that the Subversion developers are voting
whether or not to release it. We’ll keep you updated.

Considering that the changes in RC8 and RC9 are minor and unlikely to
destabilize, the Subversion developers decided not to restart the soak
period (the time to test a Release Candidate before it is called the
final release). So, unless users find showstopper bugs, Subversion will
probably release next week or the week after.

You can download RC8 binaries from openCollabNet (Windows, Red Hat Linux,
and Mac OS X). Please test RC8 and report any issues in the forum.

Btw: The release notes for Subversion 1.5 are nearing completion. You can
view the Subversion 1.5 release notes on Tigris.org. A full list of SVN
1.5 changes is available as well. Neither of these documents is final of
course. [Less]

Subversion Release Candidate 8 Posted

Posted about 1 month ago by Guido Haarmans