[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnubg] project directory structure (was: access to cvs repository)
From: |
DIG |
Subject: |
[Bug-gnubg] project directory structure (was: access to cvs repository) |
Date: |
Thu, 30 Sep 2004 13:05:53 +0200 |
User-agent: |
Mutt/1.4.1i |
On Wed, Sep 29, 2004 at 04:43:38PM +0200, Oystein Johansen wrote:
[...]
> You mean clean the directory structure of the source? I have thought of
> it, but haven't had the guts do it. I guess there is a source tree
> layout standard for gnu projects. src, doc, po, gtk, lib, win32 could be
> natural directories in the source tree.
Yes. I would say it might be the standard GNU projects directory structure
*crossed* with the logical structure of this project. By the latter I mean the
deeper separation of the engine code from the interface's code (both frontends
and backends).
Something like this?
.
|-- doc
|-- intl
|-- lib
|-- m4
|-- po
|-- resrc
| |-- sound
| |-- texture
| `-- xpm
|-- script
`-- src
|-- backend
| |-- html
| |-- latex
| `-- text
|-- engine
| `-- met
|-- frontend
| |-- curses
| `-- gtk
| `-- board3d
`-- script
The benefits: more observable and logical overall structure (you do not mix
manual's images with freshly compiled .o-files), more readable Makefiles.am.
> No! Nobody in the project have the shell access to the repository, and
> if someone had, that wouldn't have been the way of doing it. The
> repository is only changed by the cvs command. That's the law, and
> that's sacred. If we decide to change the structure, we will do it
> through the cvs commands.
If you are talking about normal CVS usage, then I agree with you. But if we
speak about reorganizing directory structure, just moving files without heavily
changing them, then I do not see why it can't be done through direct access to
the repository. Another plus is that all moved files will keep their history.
(I do it relatively often, and there is nothing intrinsically wrong with that).
I am not so sure about this "law". I believe I read somewhere that it is
possible to make some kind of appointment with the site's administration and
discuss with them our options. I am sure that they will understand and will be
willing to help. So, from the point where the structure will be decided there
are many possibilities how to change the repository (after this point, the
``developer'' is someone or group of people who will do the reorganizing,
``admin'' is gnu.org's admin):
(1) someone of developers gets (temporarily) admin's privileges, and when the
plan of the source tree is ready and when the diffs are ready, he just moves
the files and apply the diffs;
(2) regular gnu.org admins provide the developers with the tar archive of the
repository, some time later the developers are back with the new tar archive of
the repository, which is untarred into repository (or the repository is patched
by diff) by the regular gnu.org admin;
(3) same as (2), but the old project repository is copied under some other name
(e.g. gnubg-saved, maybe temporary private project?) and stays there for some
time; new tree is being tested by the developers, and when all developers, who
are able to build it, do that -- then the new tree becomes the main development
tree (we can delete saved copy);
(4) some kind of branching? but I do not see any benefit of branching, when all
that is needed is moving files inside the repository and some trivial changes
in the Makefiles.
Of course, there will be some adjustments, when the new directory plan is ready.
So, what do you think?
Best regards,
--
DIG (Dmitri I GOULIAEV)
1024D/63A6C649: 26A0 E4D5 AB3F C2D4 0112 66CD 4343 C0AF 63A6 C649