On 4/17/2017 7:26 PM, The Tick wrote:
.....
So I've goofed up by putting freetype-2.7.1/ and others into the
repository?
"Goofed up" is too strong. "Picked a different way to do it" is more
accurate. There are tradeoffs and a lot of personal preference involved.
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.
You certainly can do it that way. When you replace freetype-2.7.1 with
freetype-2.8, just rm -rf the old one and unzip the new one.
Fossil addremove will mark the entire old tree as no longer tracked and
add the new tree.
What you lose doing it this way is any continuity of history of files in
both versions. But that might not really be a loss. There's an internal
storage cost too, in that fossil might not store the new version as
efficiently as it could have, but that almost never matters given
today's price per byte of disk, and that source code is already highly
compressible by fossil's internal use of zlib.
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.
You can also tag the checkin with the library version. Probably should
do that anyway, it can help you locate where in the timeline you
introduced a particular version.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
