On Apr 17, 2017, at 8:26 PM, The Tick <the.t...@gmx.com> wrote:
>
> On 4/17/2017 9:11 PM, Ross Berteig wrote:
>> Try to avoid
>> preserving a version number as part of the folder names in the workspace
>> even if your upstream does that to you.
>
> 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.
Certainly you *can* do this, but it gives the very problem you started the
thread with, which is that you end up with duplicate copies of all files in the
depended-upon library, even if those files have not changed.
If you unpack the library into a freetype/ directory and update to new versions
in place, not only do unchanged files not take more space, Fossil’s delta
compression is likely to store the files that *do* change in far less space.
One other thing you might want to consider is simplifying the depended-upon
project’s build system.
Ideally, you’d merge the depended-upon project’s build rules into your existing
build system to avoid the Recursive Make Considered Harmful problems:
http://aegis.sourceforge.net/auug97.pdf
That takes extra work, so if you’re unwilling to do that, then at least
consider reverting the upstream project’s build system to a more “core
developer” state. If the upstream project uses Autotools, for example, you’d
check in only configure.ac and Makefile.am, not any of the files that are built
from them: configure, aclocal, etc. The upstream project may have a bootstrap
or autogen.sh type of script which rebuilds these generated files; call that
from *your* top-level build system when you bootstrap *it*.
> I guess I'd need a readme or something to tell what the current version is?
Most third-party libraries contains a ChangeLog or VERSION or NEWS type file
which gives version info. Your checkin message committing the new version
should also contain this, as should your parent project’s ChangeLog file.
> stuff gets lost in all the commit messages.
That’s one of many reasons why you should distill your commit messages into a
ChangeLog as part of every release: to document such things. My rule for
writing ChangeLog entries is that everything that could affect behavior the end
user can see goes into the ChangeLog.
The ChangeLog should be much shorter than the output of “fossil timeline”
because you’ll be removing all the checkins for behind-the-scenes changes, as
well as frequently distilling multiple detailed checkin messages into a single
brief user-focused ChangeLog entry.
That gets you a file you can trivially search afterwards. I end up going back
to my ChangeLogs roughly monthly to answer questions like “When was feature Foo
added?”
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
