[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitkeeper-users
Subject:    Re: [Bitkeeper-users] using two related repositories on windows,
From:       Marcel van der Boom <marcel () hsdev ! com>
Date:       2003-09-22 20:03:19
[Download RAW message or body]

Wayne Scott wrote:

>From: Marcel van der Boom <marcel@hsdev.com>
>  
>
>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@bitmover.com
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.
[prev in list] [next in list] [prev in thread] [next in thread]