Wayne Scott wrote:
From: Marcel van der Boom <marcel@xxxxxxxxx>
Any chance you could link the whole modules directory and then have
some file in /repos/core that says which modules are enabled for this
project? Make your build system use that file unstead of just adding
all subdirectories of the modules directory. That would be better
because right now you are not preserving which modules are used in
your revision history.
Not as we have it now, as the modules dir in the core repos als contains
directories with modules belonging to core, or am i misunderstanding?
If each module had it's own repository we could nest the repositories
(is that supported ? seem to remember it involved some perl spaghetti
from Larry), but we only symlink one directory at a time.
Yes if each module was a seperate repository then linking each module
would work. The perl stuff was to make bk appear to understand that
the whole collection of repositories was one "meta" project.
ok, good to know this for reference.
But if you are OK doing operations on each repo seperately, then you
can put them inside each other without bitkeeper having any touble.
But when bitkeeper is traversing the directories in a project and some
subdirectory happens to belong to a subdirectory of another project
then we get confused. Symlinks are OK because bk knows not to
traverse into a symlink to a subdirectory, but your Windows links are
not noticed by bk currently.
Another fact that you might be able to use is that bitkeeper will not
traverse into any directory that contains the file '.bk_skip'.
yes, but in combo with the symlink that doesn't help, because the
modules repo citool doesn't traverse them as well then.
If you don't expect developers to change any of these modules, then
you could do something like this
bk export -tplain -i'nocoremod_1/*' /repos/modules /repos/core/modules
to get a read-only copy of the data. You might have to play with that
command line a bit. Then put a .bk_skip in modules to make things
faster so bk won't even look in those directories.
This is basically what we do now, only the windows devs seem to find it
easier to do the drag and click thingie with the explorer.
The problem with this is that any changes to the modules will be lost
without the developer keeping track of them himself.
yup, that's why i would like them to use another method. The lost track
is annoying, but they regurlarly end up with a broken repos, which i
usually need to repair for them (although they usually just reclone,
which in turn i want to prevent.)
So far i understand that if we want it better we need to:
- put *all* modules in the modules repo and nest them (this breaks the
logic of our system core/modules)
- move the core/modules directory to another place
I was kinda hoping we could avoid reorganizing the repositories. Any
other alternatives? I don't mind having a complex setup, as long as it
can be scripted and works on both linux and windows, then we have 95% of
our devs covered.
marcel
_______________________________________________
Bitkeeper-users mailing list
Bitkeeper-users@xxxxxxxxxxxx
http://bitmover.com/mailman/listinfo/bitkeeper-users
To unsubscribe from this list, go to the above URL, follow instruction at the
bottom of the web page.
| 
