bug-gnubg
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]