Re: [Gnu-arch-users] Sharing individual files/subdirs between projects

[Mikhael Goikhman]

On 05 Jul 2004 09:09:39 +0200, William Dode wrote:
> 
> Mikhael Goikhman <address@hidden> writes:
> 
> > archzoom tree looks like:
> >
> >     README
> >     bin/archzoom.cgi
> >     bin/axp               # shared with axp
> >     perllib/Arch/         # shared with arch-perllib
> >     perllib/ArchZoom/
> >     perllib/AXP/          # shared with axp     
> >     tests/
> >
> > There is no requirement for the marked share points to be modifiable.
> >
> > I see 8 roads toward these requirements.
> >
> > 1) Fork each project from another and delete/add files, then use merging.
> > This seems to be too problematic to even try, since there are more
> > unshared files/subdirs than shared ones.
> >
> > 2) Create new smaller projects, one per share point. Not an option.
> >
> > 3) Nest projects (using configs). However this seems to be pretty
> > problematic with these requirements.
> 
> Why it's problematic ?

I would like to have trees like mentioned in the requirements. This is
important to simplify 1) hacking, 2) installation process, 3) releases.

Becides, I see no reason to nest the whole tree of another project that
contains a lot of irrelevant files used for testing, separate installation
(scripts, autoconf stuff), documentation and examples.

> > 4) Don't nest, but require these projects to be checked out in the same
> > directory level (possibly using the forth project and configs), then use
> > out-of-project symlinks to define share points. Works on unix.
> >
> > 5) Keep only one united super-project in arch, with distinct file names.
> > This is what I do now.
> >
> > 6) Just "cp -a" from one project to another from time to time.
> >
> > 7) Hack a system smarter than "cp -a", to duplicate the structure of
> > matched changesets (with constraints) from the master project to the
> > secondary project, and possibly vice versa too. Still no arch involved
> > in this system (no merging) that makes it difficult for me and others.
> 
> 6) and 7) seems exactly what configs do if you add an arch.config in the
> archzoom project (you don't need to create an other project for this).

Please elaborate. How do you suggest arch.config to look to implement
copying of individual files/subdirs?

> > 8) Wait for the implementation of the Tom's selection idea. Seems like
> > this is the ultimate solution ... in the future. If I understand it
> > correctly of course.
> >
> > So I am basically left with options (4), (5), (6). Do I miss anything?
> > How would you solve something like this?

Regards,
Mikhael.