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

[William Dode]

Mikhael Goikhman <address@hidden> writes:

> This is a pretty general question that is relevant to umbrella projects.
> I think I have an idea about the best solution, but I would like to hear
> suggestions from more experienced arch users.
>
> Here are the requirements, reduced for simplicity. Three real projects
> are arch-perllib, axp and archzoom.
>
> arch-perllib tree looks like:
>
>     README
>     perllib/Arch/         # dozens of files/subdirs
>     tests/
>     ...
>
> axp tree looks like:
>
>     README
>     README.arch-perllib   # shared with arch-perllib README (optional)
>     bin/axp
>     perllib/Arch/         # shared with arch-perllib
>     perllib/AXP/
>     tests/
>
> 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 ?

>
> 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).

>
> 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.
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>

-- 
William Dodé - http://flibuste.net