Hi Ross:
In message <f72d2dd1-aaba-e304-35c0-bf8f12c98...@cheshireeng.com>,
Ross Berteig writes:
>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".
>
>This is essentially why the "fossil addremove" command was invented.
>
>When an upgraded library is available, do something like this:
>
>Start with your working directory clean and stable, possibly even
>updating back to a stable point on trunk.
>
>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.
I usually rm -rf the contents of the old lib directory then unpack the
new library into the empty directory.
If you don't remove the original files in the directoru, then
addremove command won't remove any files that have been deleted from
the new version.
The rest of your stuff was spot on.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
