Re: Small repository problems

[Francesco Salvestrini]

Hi Peter,

Sorry for the delay in my replay but I couldn't reply earlier.
 
On Thursday 23 July 2009, Peter Simons wrote:
> Hi Francesco,
>
>  > I'm not acquainted with submodules. I'm just filing all my PROs and
>  > CONs before asking for a small rearrangement. At the moment I see
>  > only CONs:
>  >
>  > 1) We need 2 tags for each distribution
>  > 2) We need to fetch the gnulib repository
>  > 3) The small problems I mentioned earlier
>  >

[SNIP]

> Because of this setup, we don't need two tags to identify a release.
> Tagging 'maint' suffices, because a tag in 'maint' implicitly tags all
> of 'master', too.

I saw it later (later than my reply). Sorry for the inconvenience.

> I'm not sure what you mean by (2). The Autoconf Archive build system
> depends on gnulib, so the library has to be made available in one way or
> another. This is not a consequence of the submodule setup. The necessity
> to check-out gnulib is orthogonal to this whole question; i.e. it's
> neither an argument for nor against using submodules.

I was filing my overall PROs and CONs about the repository structure, not 
necessarily those sticked to submodules only.

Point 2 refers to the fact that the cloned and submodule updated repository is 
~68MB (gnulib ~59MB, ~8.5MB the autoconf-archive "core" only).

Since I had multiple copies of gnulib for mine and others projects I changed 
that approach slightly, using different ways (depending on the project):

A) Use a GNULIB environment variable which points to the same gnulib clone

B) Use a makefile 'update' target which downloads the required 
scripts/text-files only (from gnulib: git-version-gen, gitlog-to-changelog, 
announce-gen, INSTALL, COPYINGv2). Something like autoconf and automake do

> The initial problems you've encountered are unpleasant, of course. I
> trust that these have been solved by now?

Yes obviously.

I sent the patches and prompted for the problem because I was unaware of 
the "history" issue.

I use submodules plainly: they are part of my source trees and I cannot or I'm 
not willing to modify them from the submodule thus the ssh url in m4 
directory required the explanation that came with your mail.

> One advantage of keeping 'master' and 'maint' separate is that there is
> a clear distinction between actual macro contents and files that exist
> only as part of the release infrastructure. The vast majority of users
> will never care about 'maint' or about any of the files it contains.
> Most people care only for the macros. The current repository setup makes
> life very easy for the users in that regard. The pages
>
>   http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=shortlog
>   http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=atom
>
> ..., for instance, show only changes to the *macros*. The log isn't
> cluttered up with lots of commits that modify python code, configure
> scripts, or automake files. If we were to merge 'maint' and 'master',
> this distinction would be lost.

I could agree, from the user perspective. I feel still unpleasant from the 
developer perspective (ignorance is hard to die ... :-) ).

That approach bases itself upon the gitweb infrastructure (or cgit, or 
whatever savannah-hackers will choose to use in the future). That application 
(and its related configuration/limitations/bugs) constraints us slightly upon 
the repository structure.

What about a macro rename that could happen ? And a macro removal due to 
obsolescence ?

Since the site is built automatically ... what about building that 
per-macro-history (including obsolescence, removal and so on) automatically ?

That approach would remove that external requirement (giving us back some 
freedom) and could be better for the final user (shows removal, obsolescences 
etc.).

Dunno, my 2 cents ...

Ciao,
Francesco
-- 
Anyone who uses the phrase "easy as taking candy from a baby" has never
tried taking candy from a baby.
                -- Robin Hood