[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Sharing individual files/subdirs between projects
From: |
Mikhael Goikhman |
Subject: |
Re: [Gnu-arch-users] Sharing individual files/subdirs between projects |
Date: |
Mon, 5 Jul 2004 11:33:05 +0000 |
User-agent: |
Mutt/1.4.2.1i |
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.