On Wed, Jul 22, 2009 at 09:16:27AM +0100, James French wrote:
> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp_at_elego.de]
> >
> > If you have read the thread you were linking to all the way,
> > you will have noted that I said in that thread:
> > "Don't do tree reorgs on isolated branches."
> >
> > Seriously. Subversion is NOT ClearCase.
> > You can't just move things around everywhere and expect
> > them to fall back into place without major effort on your part.
>
> I've certainly come to expect to have to do serious work where
> subversion is concerned. Now if someone could tell me (and the
> original poster) precisely the form of this 'major effort', I'm
> certainly prepared to undertake it - I've got to.
Well, the effort consists of making sure that merges are done
only between tree structures that are compatible.
Without a concrete example, it's hard to say more than that.
> Please take it as read that I had a good reason to reorg 200 files on
> a branch. I won't go into details, but it was necessary.
Of course it's necessary! We would not have added tree conflict
detection if we thought that refactoring was not necessary.
> Also, please don't take this post negatively. I'm using your software
> for free with no contribution, so I am definitely very grateful.
> You're doing a good job, but please sort this issue out!
Sorting this issue out is a long journey.
Right now, the working copy is being rewritten.
This will, among other improvements, allow is to track renames on
the client side more reliably.
But then, we'll also need to propagate rename information to
the server. The programming interface we use to send tree changes
from client to server and from server to client is currently being
redesigned to accommodate for atomic replace operations and renames.
"But do it in a backwards compatible way, please!" I here users say
instantly. OK, we'll try.
Then it will have to be stored in the repository somehow.
There are problems with doing this the naive way -- we'll get various
problems if we simply rename nodes in the versioned filesystem.
So there will have to be some form of mapping between nodes (e.g.
copy-to information in addition to the copy-from information which
is already there) -- who knows, it's not even designed yet.
Once we have that, we'll also have to send the information back
to the client during updates and merges and make use of it there.
On the way, we'll either reach 2.0 and stop being backwards compatible,
or we will have to invent ways to keep all this compatible with the
way things work right now.
So we're really talking about changing several major parts for
Subversion's design and then changing the code base accordingly.
Guess how many active developers we have at any given time?
Check the commit list archives. This month, we've so far had
about 244 commits, made by about 13 people. (That's not counting
people making commits to code outside of the Subversion core code
which is what matters here).
So let's say we have somewhere between 10 and 20 active people
at any given time. Not all of these work on Subversion full-time.
Some of the 13 people only made 1 or 2 commits this month.
Not all of those work on the issues above. Some work on other new features.
A lot of us are also busy fixing bugs for the next minor release.
Even then, some bugs known since 1.5.0 are still not fixed.
That leaves very few man hours per week to make progress on the above
issue. There's just so much to do for our small team that progress
on things of the scale as the above happens to be very slow.
But on the bright side, more contributors are always welcome.
Do you have any good but idle developers on your teams?
We need them to make Subversion work better for you quicker!
Companies using Subversion and running into issues could also fund
currently unfunded existing developers so that they can afford to
work on Subversion full time. That would also accelerate things.
Stefan
Received on 2009-07-22 12:34:43 CEST