On 2004-10-14, "Brian W. Fitzpatrick" <firstname.lastname@example.org> wrote:
> No it most certainly does not. This would only require that you
> check out the doc/ directory.
Yes, checking out all the other translation projects. No thanks.
On 2004-10-14, Garrett Rooney <email@example.com> wrote:
> There are considerably less people working on the translations
> than there are people who check out the tree. There's no reason
> to inconveninece the many in order to make it more convenient
> for the few. I see no reason to bend over backwards to avoid
> the need for the translators to check out the entire tree.
Yes. This is why I reluctantly joined the main repository. I didn't
want to bother others, even though apparently nobody objected first.
Now it looks clear that none of the the project's administrators
really considered what using the main repository would mean.
I can see now that these conflicts are happening due to an incorrect
design of the repository tree layout. First of all, I was really
shocked to find out that the book is part of the main trunk and that
translations hang from it too. What connection is there between a
book tailored to end users and the C source of the tool the book
describes? Is there any need for the book to be part of the main
tree? Is there any need for the C developers to have a checkout
of the book in their source tree? Does Subversion build depend on
the doc directory or its contents in such a way as Windows depends
on Internet Exporer? After all, the web page for the book is not
even located at the same server as the Subversion project. So why
do they share the repository?
My previous replacement of the svn:externals property with a
duplicate copy of the tools was not well met, especially since it
involved additional +11MB of data. Surely that's not needed in the
Subversion development tree, and that's why it was removed and a
beautiful log message attached to the operation stating that the
directory should never ever be recovered again.
11MB of data. Which with Subversion's local duplication of data meant
roughly 23MB of hard disk space on each developer's hard disk. That's
certainly not needed. But why stop there? Without the tools directory
each developer is checking out between 4 and 5MB of a Spanish version
of the book. Why is this accepted by the developers? Do Subversion
developers like to checkout 5MB of useless data for them?
Řyvind A. Holm recently bumped his 2MB directory to 6MB. I will
likely bump it to that size too when I include translated images in
the same way the norwegian translation does. That should be about
12MB of data. Useless data to most subversion developers. Why keep
it? What is the acceptable size limit?
You are working to make Subversion a replacement of CVS. A key part
of the free software movement, just look at the diversity of projects
hosted by Subversion. With that goal in mind, it's simply a matter
of time until more translations are added to the repository. Imagine
that in about one or two years the existing translations have
catched up in size, and four more have been added. Expecting 5MB
of checkout data for each would mean 45MB of data. Useless data for
most of Subversion developers.
And even in that case, there would be considerably less people
working on the translations than there are people who check out
the tree, as Garrett lucidly points out. Why even allow them to
create such an inconvenience for the many in order to make it more
convenient for the few? How long until this monolithic approach
doesn't scale well any more?
Here is my request to the Subversion's administrators: please remove
the book from the doc directory and move it to an independent
repository. And when you do so, don't design the layout with a
subdirectory called translations where you throw in anything you
originally didn't care of. Move the English book into a subdirectory
called "english", and move its currently subdirectory tools to the
root of the repository. Example:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Oct 15 23:07:46 2004