Another option is to create a fossil for the 3rd party libraries, and then open that fossil --nested in a directory inside your working directory. Then nothing in that nested directory tree will be part of the main fossil. You don't even need to commit to it if you don't want. Lastly, when you don't want that version any more, remove the contents, close the repo and create a new one for the new version of the 3rd-party library.
Nested repositories is one of the things I like best about Fossil. ../Dave On 17 April 2017 at 22:26, The Tick <[email protected]> wrote: > On 4/17/2017 9:11 PM, Ross Berteig wrote: > >> On 4/17/2017 6:50 PM, The Tick wrote: >> >>> I've put a project under fossil. Since it depends on a couple other >>> libraries, I've also put those into the repository so that I am not >>> dependent on being able to download those particular versions. Now, >>> when new versions of those dependent libraries become available, I >>> want to update my project. I could just add the new versions and >>> modify my makefile. The problem I see is that over time the fossil >>> repository is going to get >really< big as it will contain a bunch of >>> obsolete stuff. >>> >>> Is there a way to handle this? I really want to keep the dependent >>> libraries in the repository since who knows what might happen to >>> someone else's open source project in the future, and in addition, it >>> makes my project "self contained". >>> >> >> >> > >> Unzip the new library on top of the old in your workspace. Try to avoid >> preserving a version number as part of the folder names in the workspace >> even if your upstream does that to you. That will just confuse life. >> >> > So I've goofed up by putting freetype-2.7.1/ and others into the > repository? > > I guess I had assumed that I could just add, say, freetype-2.8 some day > and change the master makefile as appropriate while making any other > changes that might be necessary to accommodate the new library version. > Then, I would do a commit after verifying everything still works. > > If the library's name should not contain a version string, I guess I'd > need a readme or something to tell what the current version is? I guess the > commit message could mention that, but stuff gets lost in all the commit > messages. > > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
