Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-02-01 18:11:00

AMDG

On 2/1/2011 1:27 AM, Dean Michael Berris wrote:
> On Tue, Feb 1, 2011 at 5:20 AM, Steven Watanabe<watanabesj_at_[hidden]>  wrote:
>> On 1/30/2011 4:35 PM, Dean Michael Berris wrote:
>>>
>>> With subversion, each commit is a different revision number right?
>>> Therefore that means there's only one state of the entire repository
>>> including private branches, etc.
>>>
>>
>> Yes, but I don't see how that's relevant.
>> How can the repository be in more than one state?
>> Now if only we had quantum repositories...
>>
>
> That's important because in a DVCS, there's no one repository.
> Therefore that means each and every repository clone of the original
> canonical repository out there has its own state.
>

Okay.  Let me just say this once and for all. The thing
that really bugs me when people start talking about how
wonderful DVCS's are is that as far as I am concerned,
*The physical location of the data does not matter much.*

> <snip irrelevant description of what git can do
> (along with every other version control tool
> since the dawn of time)>
>
>>> How
>>> would you track the single repository's state?
>>
>> Each commit is guaranteed to be atomic.
>>
>
> And so that means the state I have in my working copy is not a unique
> state. That means, if I've made a ton of changes locally that I
> haven't committed yet

Just don't do that.  It sounds to me like you're
imposing your DVCS development model on a centralized
VCS and trying to keep changes to yourself for a long
time.  If you don't use the tool correctly, it isn't
the tool's fault when things break down.

> and 80% of those changes conflict with changes
> in the central repo, I just say "OH FML"? Note that even if I do have
> a branch, synchronizing changes back into the source branch will be a
> PITA.
>

And it will be no matter what tool you use.
There's no way that git can somehow magically
make the conflicts go away.

>>> How do you avoid
>>> clobbering each other's incremental merges?
>>
>> If the merges touch the same files, the
>> second person's commit will fail.  This is
>> a good thing because /someone/ has to resolve
>> the conflict.  Updating and retrying the commit
>> will work if the tool can handle the merge
>> automatically.  (I personally always re-run
>> the tests after updating, to make sure that
>> I've tested what will be the new state of
>> the branch even if there were no merge conflicts.).
>>
>
> We have the same workflow except in Git, I don't have a chance to mess
> up the canonical repo if I'm not the maintainer. What happens with Git
> is that if I am a co-maintainer of a library's repo with you, then if
> I push and the merge that happens upstream is not a "fast-forward"
> (i.e. no merge conflicts will happen and is likely just an index
> update) then I have to pull the changes and merge the commits locally
> -- this is not the case with Subversion as I have to have exactly the
> same revision number in my working copy for me to be able to commit
> anything.

To be clear, the global revision number doesn't matter.
The requirement is that you have to have the most recent
versions of all the files that your commit touches.
If this happens, I /want/ to be notified, even if the
merge can be done automatically.

> Note that git works as a series of patches laid out in a DAG
> and each commit is unique, meaning each commit can be transplanted
> from branch to branch and the identity is maintained even if you had
> it in a ton of branches (or repositories).
>
>>> Remember you're assuming
>>> that you're the only one trying to do the merge on the same code in a
>>> single repository. Consider the case where you have more than just you
>>> merging from different branches into the same branch.
>>>
>>> In git, merging N remote-tracking branches into a single branch is
>>> possible with a single command on a local repo -- if you really wanted
>>> to do it that way.
>>
>> This would require N svn commands.  (Of course
>> if I did it a lot I could script it.  It really
>> isn't a big deal.).
>>
>
> Not only that, it would also require your working copy to be sync'ed
> with repo's state for the branch for which you want to do the commit.
> This synchronization is a killer in multi-developer projects touching
> the same code base.
>

This synchronization isn't necessary and depends
on how you manage your branches.  If you run into
problems here, it's self-inflicted.

>>> Of course you already stated that you don't want
>>> automated tools so if you *really* wanted to inspect the merge one
>>> commit at a time you can actually do it interactively as well.
>>>
>>
>> I didn't say that I didn't want automated tools.
>> I said that I didn't trust them.  With svn that
>> means that, before I commit I always
>> a) run all the relevant tests
>> b) review the full diff
>>
>
> And that workflow is very much supported in git as well.

Of course it is.  This is really basic usage
of the version control tool.

> I think there's fundamental impedance mismatch when you look at the
> act of developing an open source project with 100 people as compared
> to having just 2 or three people touching the same code.
>
> In the simplest case scenario of less than a handful of people are
> touching the code, heck tarballs and exchanging patches should work
> just fine -- you're going to resolve conflicts anyway. But if you have
> a lot more people doing this then you have a choice: either use a tool
> that supports thousands of concurrent developers, or use one that
> supports maybe a few tens of developers.
>
> Branches in git are a different beast from how a branch in subversion
> looks like. Basically in subversion, you're copying a snapshot of the
> code and making changes on top of that. When merging you take commits
> that are made from one branch into another using the repository
> version as the identifier for changes made in the code. That's alright
> if you only had one repository and just a few developers touching the
> code and doing the merging -- now scale that to a hundred people
> touching the same code and having one branch each, then you start
> seeing how just branches won't cut it. This is true not only for Boost
> -- imagine a hundred people working on the containers or algorithms
> collections at the same time -- especially if it wants to support a
> lot more contributors than it already has.
>

Is this ever going to happen?  Probably not.
Anyway, we aren't even close to hitting the
limits of subversion, so your concerns about
scalability are pretty much irrelevant at this
point in time.

> This goes the same for people to just want to
> maintain local Boost repositories for their own organizations and
> would want for example to fix all warnings and not have to submit
> those changes until they're ready later on.
>

Unless you assume that the entire world is using
git, which is not the case now, and will probably
never be the case, using git won't help all that
much here.  The solution to this problem is really
simple and well-known: import Boost into your
version control tool.

>>> The maintainer can then do the adjustments on the history of the repo
>>> -- things like consolidating commits, etc. -- which largely is really
>>> what maintainers do,
>>
>> Is it?  I personally don't want to spend a lot of
>> time dealing with version control--and I don't.
>> The vast majority of my time is spent writing code
>> or reviewing patches or running tests.  All of
>> which are largely unaffected by the version control
>> tool.
>>
>
> Of course in Boost, what happens is maintainers are largely the same
> developers of the project as well. Which is odd for an open source
> project the magnitude and importance of Boost.
>

Do you see a problem with this situation?  It
seems pretty fundamental to the way Boost operates.

> If you don't want to spend a lot of time dealing with version control
> then git is precisely the tool you want. If you spend a couple of
> seconds (or maybe a minute) committing things or merging them to the
> single Boost subversion repository, then you can spend a fraction of
> that (an order of magnitude less) than the time you would using git.

How exactly is saving an order of magnitude on 1% of my
development time supposed to help?  Come on.  It takes me
longer to find the right terminal, than it does to commit.

> Benchmarks abound comparing performance of git against subversion in
> most of these routine operations showing how git is much more
> efficient and better at staying out of your way than subversion is.
>

Of course there are, given all the hype about git.

> And this is so easy to fix with git because then if Dave the
> maintainer isn't paying attention, either one of us can ping a release
> manager or let everybody know that "hey, we're trying to consolidate
> changes here but Dave isn't paying attention!" and thus someone can
> pick either one of our repositories as the "canonical" repo for the
> library. Of course that promotes either one of us to be the maintainer
> -- it's a lot more fluid process that is explicitly supported and
> encouraged by the git workflow. This is the insurance mechanism and
> the "business continuity process" that is built-into the distributed
> version control systems like git, mercurial, bazaar, etc.
>

The bottleneck here is exactly the same
as the bottleneck in the current system.
- someone has to volunteer to be the new maintainer
- someone has to approve this

Using git will not change anything essential.
It will only change minor details of the process.

>>> With subversion, there's no way for something like this to happen with
>>> little friction.
>>
>> Why not?  Replace "github fork" with "branch" and
>> subversion supports everything that you've described.
>>
>
> If you made your subversion repository publicly accessible without
> need for authenticating who the user is to be able to commit changes
> then that would be true. Otherwise as it stands at the moment you need
> permission to even touch the Boost repository.

As far as I know, sandbox access is granted to pretty
much anyone who asks. Besides which, if you want to
avoid having anything to do with the official Boost,
you always have the option of importing Boost into
<insert your favorite tool here> and working off in
your own world.

> And this part turns a
> lot of people away from wanting to contribute

I'm sure that it will turn away the git users
who think they can't use anything else.  Frankly,
I don't care.

> because the other way
> around it is to submit a patch in Trac -- which is quite honestly
> painful and time consuming as heck.
>

???
Creating a diff is easy.
Uploading a file is easy.

> The concept of rebasing is really simple:
>
> 1. I branch from trunk revision 1, and make changes until revision 30.
> 2. In between r30 and r1 some things change in trunk.
> 3. I want to make my branch upto date with the changes that have been
> in trunk since r1 to r30 so I 're-base' by pulling the changes from
> trunk into my branch up to r30.
> 4. I have to (or subversion has to) remember that I've already merged
> in changes up to r30 so the next time I do the same operation, I don't
> try to pull in the changes that are already there.

Okay.  Subversion does remember this, so where's the problem?

>>>>>> c) Even if I were merging by trial and error, I
>>>>>>    still don't understand what makes a distributed
>>>>>>    system so much better.  It doesn't seem like it
>>>>>>    should matter.
>>>>>>
>>>>>
>>>>> Because in a distributed system, you can have multiple sources to
>>>>> choose from and many different ways of globbing things together.
>>>>>
>>>>
>>>> So, what I'm hearing is the fact that you
>>>> have more things to merge makes merging
>>>> easier.  But that can't be what you mean,
>>>> because it's obviously nonsense.  Come again?
>>>>
>>>
>>> Yes, that's exactly what I mean.
>>
>> Apparently not, since your answer flips around
>> what I said.
>>
>
> I meant, with *git* and because merging is almost as painless as
> possible most of the time, having more things to merge from makes it
> easier. The logic is really simple: if I can pick from more sources of
> things to merge in, I can do that all at the same time and if things
> fail, back out and exclude a source and see if things go fine. I can
> then isolate which things I would merge without having to resolve
> manual conflicts, push those to the canonical repo, and as a
> maintainer just tell the other sources "hey, synchronize with the
> state now and try again". That means it's easier for me as a
> maintainer now that I don't have to manually figure everything out, I
> can have other sources deal with it for me if they really want to have
> their stuff included.
>

Okay so what you're saying is that if the changes
are split up into smaller independent pieces,
it's easier to isolate the parts that cause
conflicts.  Is that correct?  This is (finally)
something I can make sense of.

>>> Because merging is easy with git and
>>> is largely an automated process anyway,
>>
>> If you will recall, the question I started out with
>> is: "What about a distributed version control system
>> makes merging easier?"  That question remains unanswered.
>
> I've said yes all the while here

*Sigh*  Are you even reading what I wrote?
This wasn't a yes/no question.

> and that was largely mostly because
> once you've tried it and have been in a project where the distributed
> thing is actually done, you'd see that having everything be
> synchronized is just a waste of time.
>

That has nothing to do with synchronization.

>> The best I've gotten is "git's automated merge is smart,"
>> but it seems to me that this is orthogonal to the fact
>> that git is a DVCS.
>>
>
> Why? Because it's distributed is precisely why merging is so much easier.
>

Are we even speaking the same language?
Define "distributed."

>>> merging changes from multiple
>>> sources when integrating for example to do a "feature freeze" and
>>> "stabilization" by the release engineering group is actually made
>>> *fun* and easier than if you had to merge every time you had to commit
>>> in an actively changing codebase.
>>>
>>
>> I've never run into this issue.
>> a) Boost code in general isn't changing that fast.
>
> Which I suppose is due to:
>
> 1. Lack of active contributors.
>
> 2. The process to contributing requires all sorts of permissions and
> front-loaded work on potential contributors which means even before
> people want to strart contributing they're turned off by the rigidity
> of the process and the toolset leading to 1 above.
>
> 3. See 1 above.
>

4. A lot of the code is fairly mature.  There is no
    need for continuous massive changes.

>> b) My commits are generally "medium-sized."  i.e.
>>    Each commit is a single unit that I consider
>>    ready to publish to the world.  For smaller units,
>>    I've found that my memory and my editor's undo
>>    are good enough.  Now, please don't tell me that
>>    I'm thinking like a centralized VCS user.  I know
>>    I am, and I don't see a problem with it, when I'm
>>    using a centralized VCS.
>
> Now, with a DVCS you don't have to rely on your memory too much or
> your editor's undo limit. This also, if I may say so myself, isn't a
> scalable way of doing it.
>

Sure it is.  It isn't like the chunks that I work on
are going to get bigger as Boost grows.  I know
my limits and I stay within them.

>> c) There's nothing stopping you from using a branch to
>>    avoid this problem.  If you're unwilling to use
>>    the means that the tool provides to solve your
>>    issue, then the problem is not with the tool.
>>
>
> But having to branch in a central repo compared to branching a local
> repo is the difference between night in the jungle and day by the
> beach, respectively.
>

Which means absolutely nothing to me.  I already
know that you prefer working with a DVCS.

> Unfortunately, that's not as easy as you make it sound with subversion.
>
> Let's take a simple example:
>
> 1. I branch off trunk r1
> 2. Developer B branches of trunk r99
> 3. Developer C branches off trunk r1000
>
> Now I want to merge changes from Developer B's branch into my branch
> so that I can try it out. That's fine because I'll be pulling the
> changes from r1 to r99. Now let's take the reverse, Developer C wants
> to pull from my branch, what happens? Hell breaks loose because he
> doesn't have the history in his branch about the state that was trunk
> r1..999.
>

Huh?  svn knows where you branched from.

> This kind of thing is what I'm talking about git makes easy -- because
> you know the whole history up front, even if two branches were
> branched off different points in the tree, there's no problem making
> that merge and trying to replay your changes on top of things. Of
> course the likelihood that you'll see conflicts is dependent on the
> parts of the code that is being touched, but the fact that *it's
> possible* is just powerful.
>

I just tried a modified form of what you described.
(Obviously I don't want to write 1000 changesets...)
For completeness I made 2 copies of Developer C's
branch and merged

a) my changes only.
b) my entire branch.  (Also merging B's changes)

I then merged all four resulting branches back to the trunk.
(Note that I avoided creating merge conflicts, since
that's a separate issue.)

Here's a slightly cleaned up transcript.
Starting from a blank repository:

 >svn checkout %MYREPO% working
Checked out revision 0.

 >cd working

 >svn mkdir trunk branches tags
A         trunk
A         branches
A         tags

 >svn commit -m "Set up standard repository layout."
Adding         branches
Adding         tags
Adding         trunk

Committed revision 1.

 >notepad trunk\file.txt
1. The quick brown fox jumps over the lazy dog.
2. abcdefghijklmnopqrstuvwxyz.
3. If Peter Piper picked a peck of pickled peppers...
4. When in the course of human events it becomes necessary...
5. This is a test of the emergency broadcasting system.
6. Humpty Dumpty sat on a wall.
7. Row, row, row your boat, gently down the stream.

 >svn add trunk\file.txt
A         trunk\file.txt

 >svn commit -m "Add a new file."
Adding         trunk\file.txt
Transmitting file data .
Committed revision 2.

 >perl -i~ -lpe "s/2.*/2. trunk edit\n2.5 trunk add/" trunk\file.txt

 >svn diff
Index: trunk/file.txt
===================================================================
--- trunk/file.txt      (revision 2)
+++ trunk/file.txt      (working copy)
@@ -1,5 +1,6 @@
  1. The quick brown fox jumps over the lazy dog.
-2. abcdefghijklmnopqrstuvwxyz.
+2. trunk edit
+2.5 trunk add
  3. If Peter Piper picked a peck of pickled peppers...
  4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.

 >svn commit -m "Edit the trunk."
Sending        trunk\file.txt
Transmitting file data .
Committed revision 3.

 >perl -i~ -lpe "s/(1.*)/0.5 trunk edit again\n$1/" trunk\file.txt

 >svn diff
Index: trunk/file.txt
===================================================================
--- trunk/file.txt      (revision 3)
+++ trunk/file.txt      (working copy)
@@ -1,3 +1,4 @@
+0.5 trunk edit again
  1. The quick brown fox jumps over the lazy dog.
  2. trunk edit
  2.5 trunk add

 >svn commit -m "Edit the trunk again."
Sending        trunk\file.txt
Transmitting file data .
Committed revision 4.

 >svn cp -m "Branch the trunk." %MYREPO%/trunk_at_2 %MYREPO%/branches/branchA

Committed revision 5.

 >svn cp -m "Branch the trunk." %MYREPO%/trunk_at_3 %MYREPO%/branches/branchB

Committed revision 6.

 >svn cp -m "Branch the trunk." %MYREPO%/trunk_at_4 %MYREPO%/branches/branchC

Committed revision 7.

C:\Users\Steven\Documents\boost\tmp4\working>svn up
A    branches\branchB
A    branches\branchB\file.txt
A    branches\branchC
A    branches\branchC\file.txt
A    branches\branchA
A    branches\branchA\file.txt
Updated to revision 7.

 >perl -i~ -lpe "s/6.*/6. do something./" branches\branchA\file.txt

 >svn diff
Index: branches/branchA/file.txt
===================================================================
--- branches/branchA/file.txt   (revision 7)
+++ branches/branchA/file.txt   (working copy)
@@ -3,5 +3,5 @@
  3. If Peter Piper picked a peck of pickled peppers...
  4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.
-6. Humpty Dumpty sat on a wall.
+6. do something.
  7. Row, row, row your boat, gently down the stream.

 >svn commit -m "Humpty Dumpty is obsolete."
Sending        branches\branchA\file.txt
Transmitting file data .
Committed revision 8.

 >perl -i~ -lne "print unless /4./" branches\branchB\file.txt

 >svn diff
Index: branches/branchB/file.txt
===================================================================
--- branches/branchB/file.txt   (revision 7)
+++ branches/branchB/file.txt   (working copy)
@@ -2,7 +2,6 @@
  2. trunk edit
  2.5 trunk add
  3. If Peter Piper picked a peck of pickled peppers...
-4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.
  6. Humpty Dumpty sat on a wall.
  7. Row, row, row your boat, gently down the stream.

 >svn commit -m "Remove declaration of independence."
Sending        branches\branchB\file.txt
Transmitting file data .
Committed revision 9.

 >echo 8. Developer C's cool stuff >> branches\branchC\file.txt

 >svn diff
Index: branches/branchC/file.txt
===================================================================
--- branches/branchC/file.txt   (revision 7)
+++ branches/branchC/file.txt   (working copy)
@@ -7,3 +7,4 @@
  5. This is a test of the emergency broadcasting system.
  6. Humpty Dumpty sat on a wall.
  7. Row, row, row your boat, gently down the stream.
+8. Developer C's cool stuff

 >svn commit -m "My cool changes"
Sending        branches\branchC\file.txt
Transmitting file data .
Committed revision 10.

 >svn cp -m "Duplicate C." %MYREPO%/branches/branchC 
%MYREPO%/branches/branchC2

Committed revision 11.

 >svn merge %MYREPO%/branches/branchB branches/branchA
--- Merging r3 into 'branches\branchA':
U    branches\branchA\file.txt
--- Merging r4 through r11 into 'branches\branchA':
G    branches\branchA\file.txt

 >svn diff

Property changes on: branches\branchA
___________________________________________________________________
Added: svn:mergeinfo
    Merged /trunk:r3
    Merged /branches/branchB:r6-11

Index: branches/branchA/file.txt
===================================================================
--- branches/branchA/file.txt   (revision 8)
+++ branches/branchA/file.txt   (working copy)
@@ -1,7 +1,7 @@
  1. The quick brown fox jumps over the lazy dog.
-2. abcdefghijklmnopqrstuvwxyz.
+2. trunk edit
+2.5 trunk add
  3. If Peter Piper picked a peck of pickled peppers...
-4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.
  6. do something.
  7. Row, row, row your boat, gently down the stream.

 >svn commit -m "merge from B"
Sending        branches\branchA
svn: Commit failed (details follow):
svn: Directory '/branches/branchA' is out of date

 >svn up
A    branches\branchC2
A    branches\branchC2\file.txt
Updated to revision 11.

 >svn commit -m "merge from B"
Sending        branches\branchA
Sending        branches\branchA\file.txt
Transmitting file data .
Committed revision 12.

 >svn merge %MYREPO%/branches/branchA branches/branchC
--- Merging r3 through r12 into 'branches\branchC':
U    branches\branchC\file.txt
  U   branches\branchC

 >svn diff

Property changes on: branches\branchC
___________________________________________________________________
Added: svn:mergeinfo
    Merged /branches/branchA:r5-12
    Merged /branches/branchB:r6-11

Index: branches/branchC/file.txt
===================================================================
--- branches/branchC/file.txt   (revision 11)
+++ branches/branchC/file.txt   (working copy)
@@ -3,8 +3,7 @@
  2. trunk edit
  2.5 trunk add
  3. If Peter Piper picked a peck of pickled peppers...
-4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.
-6. Humpty Dumpty sat on a wall.
+6. do something.
  7. Row, row, row your boat, gently down the stream.
  8. Developer C's cool stuff

 >svn commit -m "Merge A's changes"
Sending        branches\branchC
Sending        branches\branchC\file.txt
Transmitting file data .
Committed revision 13.

 >svn log branches\branchA
------------------------------------------------------------------------
r12 | Steven | 2011-02-01 12:38:06 -0800 (Tue, 01 Feb 2011) | 1 line

merge from B
------------------------------------------------------------------------
r8 | Steven | 2011-02-01 12:34:44 -0800 (Tue, 01 Feb 2011) | 1 line

Humpty Dumpty is obsolete.
------------------------------------------------------------------------
r5 | Steven | 2011-02-01 12:33:23 -0800 (Tue, 01 Feb 2011) | 1 line

Branch the trunk.
------------------------------------------------------------------------
r2 | Steven | 2011-02-01 12:31:08 -0800 (Tue, 01 Feb 2011) | 1 line

Add a new file.
------------------------------------------------------------------------
r1 | Steven | 2011-02-01 12:29:32 -0800 (Tue, 01 Feb 2011) | 1 line

Set up standard repository layout.
------------------------------------------------------------------------

 >svn merge -c 8 %MYREPO%/branches/branchA branches/branchC2
--- Merging r8 into 'branches\branchC2':
U    branches\branchC2\file.txt

 >svn diff

Property changes on: branches\branchC2
___________________________________________________________________
Added: svn:mergeinfo
    Merged /branches/branchA:r8

Index: branches/branchC2/file.txt
===================================================================
--- branches/branchC2/file.txt  (revision 11)
+++ branches/branchC2/file.txt  (working copy)
@@ -5,6 +5,6 @@
  3. If Peter Piper picked a peck of pickled peppers...
  4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.
-6. Humpty Dumpty sat on a wall.
+6. do something.
  7. Row, row, row your boat, gently down the stream.
  8. Developer C's cool stuff

 >svn commit -m "Merge A's changes."
Sending        branches\branchC2
Sending        branches\branchC2\file.txt
Transmitting file data .
Committed revision 14.

 >svn merge %MYREPO%/branches/branchA trunk
--- Merging r3 through r14 into 'trunk':
U    trunk\file.txt
  U   trunk

 >svn merge %MYREPO%/branches/branchB trunk

 >svn merge %MYREPO%/branches/branchC trunk
--- Merging r5 through r14 into 'trunk':
G    trunk\file.txt
  G   trunk

 >svn merge %MYREPO%/branches/branchC2 trunk
--- Merging r11 through r14 into 'trunk':
G    trunk\file.txt
  G   trunk

 >svn diff

Property changes on: trunk
___________________________________________________________________
Added: svn:mergeinfo
    Merged /branches/branchA:r5-14
    Merged /branches/branchB:r6-14
    Merged /branches/branchC:r7-14
    Merged /branches/branchC2:r11-14

Index: trunk/file.txt
===================================================================
--- trunk/file.txt      (revision 11)
+++ trunk/file.txt      (working copy)
@@ -3,7 +3,7 @@
  2. trunk edit
  2.5 trunk add
  3. If Peter Piper picked a peck of pickled peppers...
-4. When in the course of human events it becomes necessary...
  5. This is a test of the emergency broadcasting system.
-6. Humpty Dumpty sat on a wall.
+6. do something.
  7. Row, row, row your boat, gently down the stream.
+8. Developer C's cool stuff

 >svn commit -m "Merge back to trunk."
Sending        trunk
Sending        trunk\file.txt
Transmitting file data .
Committed revision 15.

In Christ,
Steven Watanabe