On Fri, 15 Oct 2004, Grzegorz Adam Hankiewicz wrote:
> On 2004-10-14, "Brian W. Fitzpatrick" <fitz@collab.net> 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.
>
If you didn't want to have each translation, why did you at all *think*
that all others wanted the docbook stylesheets that everyone who needs it
can download himself?
> On 2004-10-14, Garrett Rooney <rooneg@electricjellyfish.net> 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 think The translation in itself doesn't bother anyone, at least not me.
> 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?
>
The book is the main user documentation for the software. It is good to
include that in the release distributions. Also, when some developer adds
a new feature, it should be documented in the book. The chances of this
happening becomes even less:-) if the book is in another repository. All
other projects I've seen or worked on include their documentation in the
sources.
> 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?
>
You're missing the point that the stylesheets you added were readily
available and maintained somewhere else. That's not the case with the book
translations. I don't read Spanish, so I certainly won't use the
translation (or the .po file for that matter). However, I don't use
javahl either, so...
Also, you don't include the C compiler for a project written in C even if
it would be convenient for some people. If you want to make life easier
for you and the translators, Karl has already suggested how to set this up
without annoying the other developers. :-)
> Ø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?
I don't think hard disk space is the problem. Building and testing
subversion takes much more disk space than some translations. Others on
this list have pointed out problems other than with the size itself.
Please go back and read those messages if you don't know what I'm talking
about.
>
> 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.
>
Yes, this might be a problem in the future. Then we may have to
reconsider.
> 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:
>
Seems like you feel that we're making a difference between English and the
other languages. But remember that the English book is the master that all
translations translate from. So the English text is special in that sense.
OTOH, if other want this reorganization, I wouldn't object.
All the above being said, I think we should try to work together as
smoothly as possible. If you plan on doing something that others might
find annoying, just ask on the list. Then wait a day or two to see if any
objections are raised. Then you may avoid such nice log messages as in
r10408 in the future. You may feel that this is a limitation on your
freedom, that talking to others is a very important part of good
collaboration.
Also, remember that all of us make mistakes. (For example, search for
lundblad in the logs and then you'll see what I mean:-) I think we have to
live with this fact, but we should try to learn something from it. It
seems like this has worked very well in this project so far, and I see no
reason at all why the Spanish translation would be an exception.
Best Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 16 23:34:09 2004