Shared libraries

Phil Dixon wrote:

time.  We have been sharing libraries on a network drive but this appears

to cause some syncing problems with changes to libraries being lost even

when the libraries are only accessed through Eagle by one person.  I'm

our libraries are on a network share since 20 years or so and I

experienced any problem. I have to admit that I'm still using Eagle 5.

Oliver

--

Oliver Betz, Munich

despammed.com is broken, use Reply-To:

Oliver Betz wrote on Fri, 17 May 2013 10:18

Phil Dixon wrote:

 

>time.  We have been sharing libraries on a network drive but this

appears

>to cause some syncing problems with changes to libraries being lost

even

>when the libraries are only accessed through Eagle by one person.

I'm

 

our libraries are on a network share since 20 years or so and I

experienced any problem. I have to admit that I'm still using Eagle 5.

I would highly recommend using a revision control system (subversion and

git are both free).  That way you use a tool that is specifically designed

for multiple people accessing the same file.  And you get complete revision

control as a bonus!

In V5, the files are binary so you can setup subversion to auto-lock based

on extension.  This means that if one person locks the file no one else is

allowed to check in changes, in fact, their local copy is read-only until

they get the lock.  This keeps 2 people from making changes at the same

time.

With V6, the library file is now text based (XML).  So the tool will allow

multiple people to work on the same file and merges the changes.  If you

happen to edit the same set of lines then it will ask you how you want to

resolve.  This is unlikely to happen , though possible.

The only downside is that CadSoft didn't change the extension from V5 to V6

so it's difficult to live in a world with both versions (like we have to).

So we end up having locks on our V6 files even though it isn't necessary

since we must have locks on V5 files.  That was poor planning by CadSoft.

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

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

Phil Dixon wrote:

We have a number of Eagle licences and have been running multiple copies

of Eagle at the same time with people working on different pcbs at the

same

time.  We have been sharing libraries on a network drive but this appears

to cause some syncing problems with changes to libraries being lost even

when the libraries are only accessed through Eagle by one person.  I'm

assuming another user who perhaps is not using Eagle at that time is

somehow replacing the library via Windows sync.

 

I know this sounds like a Windows problem but what I'm really asking is,

is there a recommended way of sharing libraries between Eagle users on a

network?

 

I do realise that some sort of discipline must be in place to stop two

users simultaneously modifying the same library but that manageable.

With Eagle V5 we used version control (CVS) and personal libraries for each

engineer. Depending on which engineer created the part symbol, it went into

either the EngineerA.lbr, EngineerB.lbr, ... etc library. That prevented

EngineerA from checking something into a common library file in the version

control system, and then having it overwritten by a check-in from EngineerB.

Only EngineerA had write access to the EngineerA library, EngineerB the

EngineerB library, etc. Note that even version control locks don't fix the

issue of binary file overwrites of common files unless a higher-level

management of the files is implemented. We implemented that higher-level

management of a few core shared libraries by giving just one engineer at a

time write access to them.

With the Eagle V6 XML format, standard version control is much easier. Now

EngineerA and EngineerB can use common library files and the changes are

merged appropriately. Conflicts are rare provided the engineers aren't

modifying the same device at the same time. If they do occur, they are

resolved using the standard merge mechanisms.

I'm not familiar with Windows or Windows Sync (we're entirely Linux-based),

but I'd highly recommend setting up a true version control system for all

your Eagle projects, ie, the schematic and board files as well as the

libraries. Git, subversion, Mercurial, or whatever works on Windows.

Preferably with a remote repository. It's cheap insurance against disaster.

Robert Johnson wrote on Mon, 20 May 2013 03:30

Phil Dixon wrote:

 

With Eagle V5 we used version control (CVS) and personal libraries for

each

engineer. Depending on which engineer created the part symbol, it went

into

either the EngineerA.lbr, EngineerB.lbr, ... etc library. That

prevented

EngineerA from checking something into a common library file in the

version

control system, and then having it overwritten by a check-in from

EngineerB.

Only EngineerA had write access to the EngineerA library, EngineerB the

 

EngineerB library, etc. Note that even version control locks don't fix

the

issue of binary file overwrites of common files unless a higher-level

management of the files is implemented. We implemented that

higher-level

management of a few core shared libraries by giving just one engineer

at a

time write access to them.

I'm not a revision control expert by any means, but with subversion we set

it up to require a lock files *.sch and *.brd.  When you check those out by

default they are read-only in the OS.  When you get the lock it then

becomes writable.  Thankfully EAGLE checks that when you try to save it

(unlike Word or Excel which only check when you load the file).

While it is possible to bypass the lock and set the file read-only

manually, in general this works very well and ensures that only one person

can write the file at a time.  I think this was one of the improvements

from CVS to subversion.

HTH, cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

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

James Morrison wrote:

Robert Johnson wrote on Mon, 20 May 2013 03:30

Phil Dixon wrote:

 

With Eagle V5 we used version control (CVS) and personal libraries for

each

engineer. Depending on which engineer created the part symbol, it went

into

either the EngineerA.lbr, EngineerB.lbr, ... etc library. That

prevented

EngineerA from checking something into a common library file in the

version

control system, and then having it overwritten by a check-in from

EngineerB.

Only EngineerA had write access to the EngineerA library, EngineerB the

 

EngineerB library, etc. Note that even version control locks don't fix

the

issue of binary file overwrites of common files unless a higher-level

management of the files is implemented. We implemented that

higher-level

management of a few core shared libraries by giving just one engineer

at a

time write access to them.

 

I'm not a revision control expert by any means, but with subversion we set

it up to require a lock files *.sch and *.brd.  When you check those out

by

default they are read-only in the OS.  When you get the lock it then

becomes writable.  Thankfully EAGLE checks that when you try to save it

(unlike Word or Excel which only check when you load the file).

 

While it is possible to bypass the lock and set the file read-only

manually, in general this works very well and ensures that only one person

can write the file at a time.  I think this was one of the improvements

from CVS to subversion.

 

HTH, cheers,

 

James.

Hi James,

I was getting a bit pedantic when I wrote about lock issues Like most

version control systems subversion doesn't lock across multiple developer

branches, hence if DevA is working on BranchA and DevB on BranchB and both

are working on FileC, placing a lock on FileC in the trunk won't read-only

lock the files in the developer branches. This is a software/web development

issue really; working with Eagle libraries in branches isn't something most

sane Eagle users would (or should) consider. For Eagle V5 I'd definitely use

subversion these days if I was starting from scratch, for precisely the

binary lock features you mention. Obviously, the XML text file format of V6

solves the problem even more elegantly.

Robert Johnson wrote on Tue, 21 May 2013 01:44

James Morrison wrote:

 

Robert Johnson wrote on Mon, 20 May 2013 03:30

Phil Dixon wrote:

 

With Eagle V5 we used version control (CVS) and personal libraries

for

each

engineer. Depending on which engineer created the part symbol, it

went

into

either the EngineerA.lbr, EngineerB.lbr, ... etc library. That

prevented

EngineerA from checking something into a common library file in the

version

control system, and then having it overwritten by a check-in from

EngineerB.

Only EngineerA had write access to the EngineerA library, EngineerB

the

 

EngineerB library, etc. Note that even version control locks don't

fix

the

issue of binary file overwrites of common files unless a

higher-level

management of the files is implemented. We implemented that

higher-level

management of a few core shared libraries by giving just one

engineer

at a

time write access to them.

 

I'm not a revision control expert by any means, but with subversion

we set

it up to require a lock files *.sch and *.brd.  When you check

those out

by

default they are read-only in the OS.  When you get the lock it

then

becomes writable.  Thankfully EAGLE checks that when you try to

save it

(unlike Word or Excel which only check when you load the file).

 

While it is possible to bypass the lock and set the file read-only

manually, in general this works very well and ensures that only one

person

can write the file at a time.  I think this was one of the

improvements

from CVS to subversion.

 

HTH, cheers,

 

James.

 

Hi James,

 

I was getting a bit pedantic when I wrote about lock issues Like

most

version control systems subversion doesn't lock across multiple

developer

branches, hence if DevA is working on BranchA and DevB on BranchB and

both

are working on FileC, placing a lock on FileC in the trunk won't

read-only

lock the files in the developer branches. This is a software/web

development

issue really; working with Eagle libraries in branches isn't something

most

sane Eagle users would (or should) consider. For Eagle V5 I'd

definitely use

subversion these days if I was starting from scratch, for precisely the

 

binary lock features you mention. Obviously, the XML text file format

of V6

solves the problem even more elegantly.

Agreed, branching is something that would likely just cause more problems

than it solves, at least in general.

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

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