I've never really been able to manage user-libraries particularly well in Eagle. The problem becomes exacerbated when moving projects from computer to computer, and even worse when trying to maintain some sort of version control. This came to a head yesterday when I did an Eagle version update, and simply rolled it back rather than dealing with issues the right way (complicated by trying to do some pro-bono consulting on a feel-good project that I need to keep entirely separated from the resources of my employer).
The closest I've come to being anywhere near happy is to maintain a user library for each and every project, and include it as part of the subversion set. This, however, has some real limitations, but boy, it certainly makes things unambiguous.
Is there a good way to maintain a user library tree that's friendly for portability and version control?
Best Answer
One major problem that prevented proper version control was the binary library format that Eagle 5 and earlier use. I guess you are already aware that they changed the format to plain text XML with Eagle 6.
We use Subversion for version control, but thats just a personal choice. Thanks to the XML format we can now perform diffs and thus following changes became much easier. It is now sufficient to check the changes during the commit, rather than having to make notes about it during development.
Our general approach:
All our libraries share one folder in the trunk. We have one "common" library where all components are clumped together, that don't match the content of one of the other more specialized libraries. From time to time we extract fitting "groups" of components to their own library, cleaning up the common one. We always check out the whole trunk to our working copy, which resides in a subdirectory of Eagles \lib folder. All files are attributed as "needs-lock" to prevent corruption, but this may no longer be necessary since we could make manual corrections to XML.
Its a good thing to include the general part numbers when writing the SVN logs. So its easy to check the revision history to prevent doing some work twice.
As a side note: If you require a project specific library that contains all components of a specific board, there is an ULP script that comes with default Eagle installation. It extracts all used components into a single lbr file.
In the end, the internal library management from eagle is just not good and that is something we can't do much about.