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

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?

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.