Does the library editor tool lock a file while editing it?

On 5/13/2014 3:05 PM, Jesse Banks wrote:

I am working in a git controlled evnvironment with several other

engineers. Currently we each have a local copy of our libraries that are

sync'd through git. The problem of merging libraries files after a Git

pull is becoming excessive.

 

We'd like to store all files in a folder on an NFS server accessable by

all users. The libraries would still be version controlled by git, with

a periodic commits. When an engineer is editing a library, the file is

read only to all other users. the other users can view but not

concurrently edit the file.

 

does the eagle library editor tool lock open files?

Hi Jesse,

EAGLE does not lock open files. Other version control systems have this

feature and every setup is different. I'm suprised that Git doesn't

support this as comprehensive a tool as it is.

There are no immediate plans to implement such a feature and

historically that is something we have left to the VCS.

hth,

Jorge Garcia

Why is this not a useful feature? Having eagle elements properly opening and locking active files seems like a useful feature.

I ask this because it seems like the VCS has no idea what any other software is doing with the file. If the shecmatic editor looks into library X, does the VCS realise this is a read only action? Whereas the library editor tool will likely make changes to the file, so it should be locked. how does VCS determine the actions of the software, if not from that software as it opens the file?

Jesse Banks wrote:

I am working in a git controlled evnvironment with several other engineers. Currently we each have a local copy of our libraries that are sync'd through git. The problem of merging libraries files after a Git pull is becoming excessive.

If you're having a problem merging libraries, that suggests to me that your libraries are too large and/or too complex.  Have you considered splitting them up and using more small library files?  Are you really making that many changes to your libraries?  If so, merging issues are probably a symptom of a larger work flow problem.  The whole point of a distributed revision control system like Git is to keep local copies of everything and work independently, then periodically merge changes.

We'd like to store all files in a folder on an NFS server accessable by all users. The libraries would still be version controlled by git, with a periodic commits. When an engineer is editing a library, the file is read only to all other users. the other users can view but not concurrently edit the file.

Speaking as a Linux System Administrator, NFS is evil!  If you don't have to, don't use it.  I'd suggest Unison instead: Unison File Synchronizer

If you really want to have a central master repository with file locking, you will probably be better off switching to Subversion (SVN) instead of using Git.  Here's a discussion of file locking with SVN: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.locking  That seems like a better fit for what you are talking about...

Jesse Banks wrote on Tue, 13 May 2014 15:05

I am working in a git controlled evnvironment with several other

engineers. Currently we each have a local copy of our libraries that

are

sync'd through git. The problem of merging libraries files after a Git

pull is becoming excessive.

 

We'd like to store all files in a folder on an NFS server accessable

by

all users. The libraries would still be version controlled by git,

with

a periodic commits. When an engineer is editing a library, the file is

read only to all other users. the other users can view but not

concurrently edit the file.

 

does the eagle library editor tool lock open files?

 

If not, is it possible to easily integrate this feature? without any

other version control or check-out software.

Hello Jesse,

Don't worry about all the haters, you're doing the right thing using

serious revision control for your libraries.  I have worked at a lot of

companies and library mismanagement is the number one reason boards come

back not working.  I have over 1500 unique devices in my library and it's

been in SVN control since the beginning (over a decade now).

I would however recommend that you don't use an NFS mount but force

everyone to use revision control client to check out latest version to

their machine.  I think that is cleaner and you can then update your local

copy of the library at a time suitable for your project (which might not be

suitable for another).

The short answer is don't expect EAGLE to change it's behaviour.  And I'm

not sure I want it to.

Use your revision control client to get the effect you would like.  I

haven't used git but if SVN clients can be configured to auto-lock certain

files then certainly git should be able to do it.  If I lock the file using

SVN then no one else can get a lock on it.  And the file is read-only on

the file system until SVN gets a lock.  I think that is the effect you are

after.

That would be my advise.  Another reason for wanting a full update report

so you can see what has changed in the library under your feet -- that

would help you out greatly in your situation (see thread from a few days

ago on that topic).

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

Take advantage of v7 License Promotion right now at

http://www.eaglecentral.ca

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

I exist in a Git + NFS environment and need to find a solution in this space. The rev control problem is the origional problem: merging XML files. Our current tools are not capable of identifing file changes correctly, and it takes a ton of man hours to resolve.

if two users have added parts to the same library (think resistors, caps, inductors) the merge tool sees the new entries in contension. each user has appended the xml list in the library and the merge tool thinks they are in conflict, instead of seperate new entries. maybe a merge tool change is in order.

Our current motion: give a single "cad" user modify rights to the libraries, and all users eagle "directories" are pointed at the nfs shared library directories with read only access. Each user can make library changes by logging into a shared vnc session. then it is obvious when libraries are being modified. the pit fall of this: only one user may change libraries at a time. Bonus: all users have most recent changes instantly. I'm not totally convinced of this plan.

We could probably just keep file revision control using git if the xml merge tool were more powerful. Any sugestions?

James Morrison wrote:

I haven't used git but if SVN clients can be configured to auto-lock certain files then certainly git should be able to do it.

Git really has no concept of a central server, so there is nothing built in to do any kind of file locking.  Because you have your own copy of everything, it is assumed that you have absolute control over your copy and that nobody else can get to it, so no locking is needed.  It's the same with all distributed version control systems.

That said, apparently there is an access control layer that you can install over Git that gives you more of an SVN-like experience: Gitolite

Jesse Banks wrote:

I exist in a Git + NFS environment and need to find a solution in this space. The rev control problem is the origional problem: merging XML files. Our current tools are not capable of identifing file changes correctly, and it takes a ton of man hours to resolve.

 

if two users have added parts to the same library (think resistors, caps, inductors) the merge tool sees the new entries in contension. each user has appended the xml list in the library and the merge tool thinks they are in conflict, instead of seperate new entries. maybe a merge tool change is in order.

It's too bad that Cadsoft switched to the XML file format.  Sigh.  Oh well, we're here now.  I started to write some XML tools to work with EAGLE files, but then I gave up and just started using a couple export ULPs to create script files that are easier to deal with under revision control.  At some point, I'll go back and see what I can do with the XML...

We could probably just keep file revision control using git if the xml merge tool were more powerful. Any sugestions?

Check out:

Project: Merge - Professional Two/Three-Way XML Compare and Merge

The "3DM" XML 3-way Merging and Differencing Tool

https://versioncomparer.codeplex.com/

There are some academic papers online about different diff and merge algorithms for XML, if you're having trouble sleeping.

Another option might be to invest in one of the dedicated library management tools that can export EAGLE libraries...

On 13/05/14 21:51, Jesse Banks wrote:

Why is this not a useful feature? Having eagle elements properly opening

and locking active files seems like a useful feature.

 

It may, or may not, be useful. Many programs do attempt to use file

locking (MS Word and OpenOffice for example) to avoid conflicts. The

result is often that annoying false positives get in the way. I've

certainly had a lot of annoyance with ooffice refusing to open files on

network drives because the NFS lock protocol was being iffy.

I ask this because it seems like the VCS has no idea what any other

software is doing with the file. If the shecmatic editor looks into

library X, does the VCS realise this is a read only action? Whereas the

library editor tool will likely make changes to the file, so it should

be locked. how does VCS determine the actions of the software, if not

from that software as it opens the file?

The philosophy behind VCS doesn't assume sharing of working files.

Indeed it makes exactly the opposite assumption - everyone on the team

WILL have their own local working copy, so that interim versions they

are experimenting with don't cause other people problems. These working

copies are kept separate and protected or merged as required. This is a

fundamentally good way to work, and cannot be handled by any application

other than the VCS.

Now there are two options for handling the situation where multiple

people want to work on the same file. Either they are all allowed to

modify their local copy and the changes are then merged (the default GIT

approach) or the repository copy is the master and all working copies

are forced to be read-only unless an explicit "repository lock" is

obtained. This function cannot be done by anything other than the VCS.

In general, file locking by every application on the system so that all

files can be shared, is a nasty hack that copes only with a very small

team who aren't controlling their data at all well. Relying on a VCS to

perform working copy management is a far better approach.