On 11/6/14, jose isaias cabrera <jic...@cinops.xerox.com> wrote: > > Greetings! > > First of all, I want to thank you whomever was the creator of this wonderful > > utility. Props to you.
That'd be drh (Richard Hipp) and a collection of contributors. > I have a setup on my Windows PC where I have many sources of various > languages. That will be another question later, but today, I have a > project, which I created a repo for it, but I have libraries somewhere else. > > Imagine this scenario: > > Project lives on: c:\sources\d\MyProject\MyProject.d > Libraries used by this project live on: c:\D\import > > \my\lib\aaa.d > > \my\lib\bbb.d > > \my\lib\ccc.d > > \my\lib\ddd.d > > \my\lib\eee.d > > \my\lib\fff.d > > \other0\lib\aaa.d > > \other1\lib\aaa.d > > The problem is that when I make changes to the to the > c:\sources\d\MyProject\MyProject.d everything is fine I get the new version > etc. Yes, because those files are in the repositorys working directory... > But, when I make changes in c:\D\Import, the changes are not being > checked in. Because these are not known to the repository, and are definitely outside the scope of it's "working directory hierarchy". > I know I can open another repo and keep track of them like > that, but is there another way where I can point to another directory and > still use the repo for c:\sources\d\MyProject\MyProject.d? You need to get that ./D/* under the umbrella of the top-level of your working directory. You could move it there, and run it from there. That could be problematic if that lib/code is shared among people or projects. If you don't _move_ it there, you could make copies of it. Obviously storing this code twice will increase your storage requirements (although, as I type this, if you're using a filesystem like ZFS w/ de-dupe capabilities, this might not necessarily be true, but I digress...). I do this (copying code) for projects of mine that depend on third party libraries... when a release of the third-party code is released, I'll update my local copy too. This is nice for a couple reasons: 1) You build against code you know (ie: your project-local copy) 2) You have that code in your repo -- so in the future if you can't find libxyz-1.1.9 from the vendor, you might have your own copy of what you care about 3) Having the code "in-scope" as far as a project goes means it's simple(r) to browse it's functions, #defines, etc during the course of your development. > I hope I was > clear enough. Thanks. Hope I understood clearly, and this helps. -bch > josé > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
