On 2/8/07, John Arbash Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Angela wrote: > ...I toyed with the idea of > having the whole root of the drive as a shared repository and just define > branches under it, but then I do have a few directories that I don't want > versioned (Installers, Images, personal stuff, etc) and wasn't sure what > impact having those non-versioned directories inside might have on the > shared repository. Additionally, I had already started versioning the > Source > folder, with the shared repository on a per-project basis, and wasn't sure > how having a shared repository within another shared repository work (I'm > thinking it wouldn't). Or, how to move history of a repository into a > shared > repository. It works fine, things underneath the nested directory are just tracked by the closest one. It may cause confusion as users, but bzr handles it without problem. What *could* cause problems is introducing an intermediate shared-repository after you already have branches, because that will block their view of the original repository. (I can explain more if you want) In general, I don't recommend having working trees in locations that are meant to be shared between people, because not everyone has the same access rights to update the working tree. (We work pretty hard to leave you working tree rights alone, and try to keep your .bzr/* files accessible). </blockquote><div> I think I understand the intermediate shared repository thing. :) Regarding the working trees in locations shared between people -- do you mean that it would be better to have no working trees at all at the server computer? It's being used as the file server as well, hence the actual documents are there. I've currently set the root of the files partition to be shared across the network and users can modify contents (I assumed the latter would be needed for remote checkout commits). I don't mean for these files to be visible anywhere except for the LAN I've set up -- in that view are the access rights a possible problem? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, while it works just fine over a local, or '\\host\foo' path (which is effectively local to bzr, same as an NFS mount). You will have some problems if you start trying to access it over ssh, ftp, etc. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> As far as unversioned files, bzr doesn't really care. Again it is something that users might get confused about (is this versioned or not). And I always advocate versioning *everything* (well, almost everything :) ... > > Would using the smart server be a better option? I can always install it as > a service on the server computer if needed. "local" access is fine. It just depends how it will scale up. I thought you were using 'sftp' rather than 'bzr+ssh'. The difference really comes in if you wanted to start accessing these files from over the internet (rather than over the local network). Because there you wouldn't really want to have an open Windows share. And in those circumstances I would recommend not having working trees, and using bzr+ssh over sftp.</blockquote><div> I see, I see. So if I wanted to access my files over the 'net, that's when I need the smart server? And not having working trees. Hmm, would it be possible to change all these at a later date to that sort of format? It's not important for me (at least right now) to be able to access my files if I have no connection to my LAN, although that need *might* change at a later date -- though not very likely. xx Angela </div></div> -- And I write in my seasonal plume. <a href="http://seasonalplume.net">http://seasonalplume.net</a> <a href="http://indisguise.org">http://indisguise.org</a>