Corrupted project file?

I am having the same issue.   In my case it is a design created in Version 7.1, and I get the same errors if I try to open in either Version 7.1 or 7.5   I get similar warnings and errors for both the SCH and BRD files, line numbers are different buth they are both worried about an invalid/missing attribute.

Warning(s):

line 1285: invalid value '' for attribute 'name' in tag <signal>

Error:

line 1301, column 9: invalid/missing attribute 'name' in tag <signal>

Do I need to recreate the whole design from scratch, or can I salvage this?

Mark Sauerwald wrote on Thu, 07 January 2016 03:51

Do I need to recreate the whole design from scratch, or can I salvage

this?

Hi Mark,

Hopefully Warren's answer above should sort you out but just relating to

your final comment, it's always a good idea to keep backup's of earlier

version so if anything get's lost/corrupted you can always go to the last

backup. Since eagle now uses a text based rather than binary file format

you can do this nicely and track your changes with a version control

system. I use Git for all my projects and I check in regularly with a

description of exactly what I have changed so I can always go back and look

what I have done over the history of a design which can be really useful on

a big project with lots of changes. You then also have easy backups to

another machine or an off-site git server. You simply check in changes and

then push them to the remote location. Doing this means you'll never have

to ask the above question as you'll know you can always go back to the last

known good check in if something bad happens.

Best Regards,

Rachael

--

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

Thank you for your advice Rachel and Warren for the suggestion.   I'll try the text editing suggestions out when I get home tonight - I use Eagle at home, and Altium at work, and there is always a transition period when I jump from one system to the other, but the text editing strategy looks like a good place to explore!   I was dreading having to redo this design from scratch, it is 10 sheets of schematic so it would have been some work!

At work, we use Perforce for version control and sharing - but I am not as diligent with my projects at home as I am at work.    I should look for a middle of the road solution and GIT looks interesting, I'll have to try that out.

Mark

On 07/01/16 17:06, Mark Sauerwald wrote:

At work, we use Perforce for version control and sharing - but I am not

as diligent with my projects at home as I am at work.    I should look

for a middle of the road solution and GIT looks interesting, I'll have

to try that out.

At work I have Visual Source (un)Safe inflicted on me but all my home

projects live in Subversion, at least partly because it's such a doddle

to administer.

Just to add a little, prompted by Rachael,s comment.

Eagle stores backups each time you save so the last of these may work for

you.

See the manual that explains the file naming of the saves and automatic

backups.

If you had done quite a bit of work since that last save maybe there's a

bit to much of a difference to use it and hence getting to work with the

text editor is the way to go.

What could be of value is, The backup may have exactly what you need to

repair the broken files so once you locate it, a simple cut and paste will

get you going and possibly the Schem and Board will be consistent.

Warren

--

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

I've worked extensively with a number of open-source source management

tools, including Subversion and GIT. For the home user I recommend

Subversion over GIT.

GIT is extremely powerful. It's designed explicitly to support massively

parallel development with very powerful branching and merging

capabilities. If you know how to use it it's great. However, it's also

cryptic, hard to learn for many people, and a real pain when it breaks.

Subversion is far more limited. It depends on having a central

repository for your projects. That's a bad thing if you're trying to

manage multiple parallel development efforts, but most basic users find

it easier to learn and use.

I spend much of my professional life developing Linux kernel code. That

means I have a fair bit of experience using GIT, and would consider

myself a fairly competent user. I also use GIT to manage my personal

projects, mainly because I was using GIT so much I found I was

forgetting how to do things with Subversion.

One of the keys to successful use of a source management system is

making sure the important stuff gets committed, and none of the garbage

gets committed. For example, Eagle creates "backup" files by renaming

the current version of its files to the "backup" name before creating

the new version. None of these "backup" files should ever be committed

to your source management system because they're basically useless

garbage you'll never want to use. If you find yourself thinking you

might want to go back to one of those older versions, that a sign you're

not committing your work often enough!

One of the ways to make this easier is to have the source management

system ignore the files you don't want to commit. To have GIT ignore the

"garbage" files Eagle creates, create a file called ".gitignore" in the

top directory of your project with the content between the lines of hashes:

###########################

.eaglerc

.cache/

.fontconfig/

.config/

*.b#[0-9#]

*.l#[0-9#]

*.s#[0-9#]

*.pro

###########################

The file name may be a bit different on Windows or Mac systems. I don't

use GIT on these systems.

You can do something similar with Subversion by setting the "svn:ignore"

property, or set the global-ignores option in its config.

On 01/07/2016 12:06 PM, Mark Sauerwald wrote:

Thank you for your advice Rachel and Warren for the suggestion.   I'll

try the text editing suggestions out when I get home tonight - I use

Eagle at home, and Altium at work, and there is always a transition

period when I jump from one system to the other, but the text editing

strategy looks like a good place to explore!   I was dreading having to

redo this design from scratch, it is 10 sheets of schematic so it would

have been some work!

 

At work, we use Perforce for version control and sharing - but I am not

as diligent with my projects at home as I am at work.    I should look

for a middle of the road solution and GIT looks interesting, I'll have

to try that out.

 

Mark

 

--

To view any images and attachments in this post, visit:

http://www.element14.com/community/message/170956

 

I've worked extensively with a number of open-source source management

tools, including Subversion and GIT. For the home user I recommend

Subversion over GIT.

GIT is extremely powerful. It's designed explicitly to support massively

parallel development with very powerful branching and merging

capabilities. If you know how to use it it's great. However, it's also

cryptic, hard to learn for many people, and a real pain when it breaks.

Subversion is far more limited. It depends on having a central

repository for your projects. That's a bad thing if you're trying to

manage multiple parallel development efforts, but most basic users find

it easier to learn and use.

I spend much of my professional life developing Linux kernel code. That

means I have a fair bit of experience using GIT, and would consider

myself a fairly competent user. I also use GIT to manage my personal

projects, mainly because I was using GIT so much I found I was

forgetting how to do things with Subversion.

One of the keys to successful use of a source management system is

making sure the important stuff gets committed, and none of the garbage

gets committed. For example, Eagle creates "backup" files by renaming

the current version of its files to the "backup" name before creating

the new version. None of these "backup" files should ever be committed

to your source management system because they're basically useless

garbage you'll never want to use. If you find yourself thinking you

might want to go back to one of those older versions, that a sign you're

not committing your work often enough!

One of the ways to make this easier is to have the source management

system ignore the files you don't want to commit. To have GIT ignore the

"garbage" files Eagle creates, create a file called ".gitignore" in the

top directory of your project with the content between the lines of hashes:

###########################

.eaglerc

.cache/

.fontconfig/

.config/

*.b#[0-9#]

*.l#[0-9#]

*.s#[0-9#]

*.pro

###########################

The file name may be a bit different on Windows or Mac systems. I don't

use GIT on these systems.

You can do something similar with Subversion by setting the "svn:ignore"

property, or set the global-ignores option in its config.

On 01/07/2016 12:06 PM, Mark Sauerwald wrote:

Thank you for your advice Rachel and Warren for the suggestion.   I'll

try the text editing suggestions out when I get home tonight - I use

Eagle at home, and Altium at work, and there is always a transition

period when I jump from one system to the other, but the text editing

strategy looks like a good place to explore!   I was dreading having to

redo this design from scratch, it is 10 sheets of schematic so it would

have been some work!

 

At work, we use Perforce for version control and sharing - but I am not

as diligent with my projects at home as I am at work.    I should look

for a middle of the road solution and GIT looks interesting, I'll have

to try that out.

 

Mark

 

--

To view any images and attachments in this post, visit:

http://www.element14.com/community/message/170956

 

reece wrote on Fri, 08 January 2016 03:10

I've worked extensively with a number of open-source source management

tools, including Subversion and GIT. For the home user I recommend

Subversion over GIT.

Not wishing to turn this thread into a SVN vs GIT debate, there are enough

of those all over the internet anyway! But... I'm not convinced GIT is any

harder to use if you just use the basic subset of functionality it has in

common with SVN. Just ignore the extra functionality until you become more

familiar with the tool. Then you only really need 4 commands, git push, git

pull, git commit and git checkout. If you're unfortunate enough to be

saddled with windows then you're also likely using Tortoise for SVN so can

use Tortoise for GIT too and the UI is really similar.

The down side of SVN for the home is it requires a central server. This is

fine if you have a spare machine to sun it on. You could run it locally but

it means your backup to your SVN server is on your local machine.... With

GIT you can simply copy the repository for backup and it's complete and

just works. Also you can make your remote repository a USB stick so you put

that in, push your changes to it and take it away and that's your backup

sorted.

Not that it really matters which one you choose of course, it's down to

personal preference at the end of the day and for keeping track of Eagle

files they're both more than up to the job.

Best Regards,

Rachael

--

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

Rachael schrieb:

The down side of SVN for the home is it requires a central server.

JFTR: It does not, definitely.

This is

fine if you have a spare machine to sun it on. You could run it locally but

it means your backup to your SVN server is on your local machine.... With

GIT you can simply copy the repository for backup and it's complete and

just works. Also you can make your remote repository a USB stick so you put

that in, push your changes to it and take it away and that's your backup

sorted.

The same for SVN.

Not that it really matters which one you choose of course, it's down to

personal preference at the end of the day and for keeping track of Eagle

files they're both more than up to the job.

Yes - however, using both with Tortoise, personally I strongly prefer

SVN over GIT. It appears much more straight-forward to me.

SCNR: <http://xkcd.com/1597/>

Maybe it's just a matter of personal taste...

Tilmann

On 08.01.2016 10:25, Tilmann Reh wrote:

 

Yes - however, using both with Tortoise, personally I strongly prefer

SVN over GIT. It appears much more straight-forward to me.

Moving over to a version control discussion here, but nevermind.

To add even more preferences, mine is CVS, but I am only able to manage

it via eclipse (eclipse.org). If I dont have eclipse, I would be pretty

much lost. The diff viewer in eclipse is part of this package.

The biggest challenge with version control is to avoid loosing your data

when doing something wrong. It is not something you should start

experimenting with until you know enough of it. You have to know what

can go wrong before starting. It is very easy to overwrite and loose

your local changes if you do it wrong. I found the terminology (and

still does) a bit weird. Terms like push/pull/commit/update are to me

still not clear, although I am now pretty confident with the basics of

CVS and different version control systems. Of course, the ones we talk

about here is mostly useful for ascii files where you can easily diff.

GUI tools together with diff tools will add value to binaries and non

human readable text (xml) as well.

Tilmann Reh wrote on Fri, 08 January 2016 09:25

JFTR: It does not, definitely

Yep, it seems you are right....

Tilmann Reh wrote on Fri, 08 January 2016 09:25

The same for SVN.

Yes but don't you have to have your main repository hosted on the USB stick

for this? Then if anything happens to that USB stick do you lose a lot of

history or is it all in the local working copy still and can be recreated?

I seem to recall having an issue relating to losing history in SVN in the

past but I can't remember the cause. Off topic for here anyway.

Tilmann Reh wrote on Fri, 08 January 2016 09:25

Yes - however, using both with Tortoise, personally I strongly prefer

SVN over GIT. It appears much more straight-forward to me.

 

SCNR: <http://xkcd.com/1597/>

 

Maybe it's just a matter of personal taste...

For what is needed here it's definitely a personal taste thing as they'll

both do the job just fine but I personally don't find GIT any more

difficult to use than SVN, they're both really simple for this particular

use case and I have never had to do as per that cartoon :d

--

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

Morten Leikvoll wrote on Fri, 08 January 2016 09:46

Moving over to a version control discussion here, but nevermind.

Yep I'm conscious that we've hijacked the original thread topic somewhat!

Morten Leikvoll wrote on Fri, 08 January 2016 09:46

To add even more preferences, mine is CVS, but I am only able to manage

it via eclipse (eclipse.org). If I dont have eclipse, I would be pretty

much lost. The diff viewer in eclipse is part of this package.

There are lots of UI tools available for CVS/SVN/GIT/Mercurial/whatever on

Windows/OSX/Linux so you always have the choice not to use the command line

tools if you don't want to and the graphical history viewers available show

the diff between versions well.

Morten Leikvoll wrote on Fri, 08 January 2016 09:46

The biggest challenge with version control is to avoid loosing your

data when doing something wrong. It is not something you should start

experimenting with until you know enough of it. You have to know what can

go wrong before starting. It is very easy to overwrite and loose your

local changes if you do it wrong. I found the terminology (and still

does) a bit weird. Terms like push/pull/commit/update are to me still not

clear, although I am now pretty confident with the basics of CVS and

different version control systems.

There are loads of basic tutorials available on how to get going which will

help avoid any issues. I am not sure how you'd lose local changes with GIT

or SVN very easily with single user basic usage and no branching etc. If

you tried to check out on top of a working directory with uncommitted

changes both of these tools would let you know about it and make you check

in your uncommitted changes first. Maybe it's a CVS thing?

Morten Leikvoll wrote on Fri, 08 January 2016 09:46

Of course, the ones we talk about here is mostly useful for ascii files

where you can easily diff. GUI tools together with diff tools will add

value to binaries and non human readable text (xml) as well.

So one thing I found a while back is Eagle Automation:

https://pypi.python.org/pypi/eagle_automation/0.1.12

I've not currently got it set up and working but one of my clients did and

one of the things it allows you to create a graphical diff of your

schematic or board between two versions within Git. It'll show you

graphical representations with highlights where all the changes are so you

can see easily where you've changed stuff. It's really quite cool and it's

on my list of things I really need to get working on my own setup.

Maybe it would be a nice feature if Eagle had some built in support for

SVN/GIT now that it's design and library files are ASCII based? Maybe they

could even implement a way to highlight differences from previous versions

right in the schematics, layout or libraries?

Best Regards,

Rachael

--

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

Rachael schrieb:

Yes but don't you have to have your main repository hosted on the USB stick

for this? Then if anything happens to that USB stick do you lose a lot of

history or is it all in the local working copy still and can be recreated?

I seem to recall having an issue relating to losing history in SVN in the

past but I can't remember the cause. Off topic for here anyway.

First of all: if you rely on an USB stick, you're completely lost

anyway. USB sticks are (by far) the least safe storage media...

Of course a proper backup scheme is essential for all of your data,

including the repository (or repositories - I use separate repos for

each project).

If you really lose the repo, all you keep is the current WC and the

history (AFAIK). I think this applies to most/all version control systems.

I didn't check yet if it's possible to recreate former versions from

that local history - it just doesn't matter to me since I always do my

backup homework.

Tilmann

Tilmann Reh wrote on Fri, 08 January 2016 10:23

First of all: if you rely on an USB stick, you're completely lost

anyway. USB sticks are (by far) the least safe storage media...

Yep, completely agree, I use a GitLab server (which is then backed up as

part of my backup process) and push all my changes to that. This suggestion

of a USB stick (although it could also be a USB HDD) was purely as a way to

have an easy way to make a regular backup of a local GIT repository for

those without a proper infrastructure (e.g. for typical home use).

Tilmann Reh wrote on Fri, 08 January 2016 10:23

Of course a proper backup scheme is essential for all of your data,

including the repository (or repositories - I use separate repos for each

project).

Absolutely, especially essential for anything relating to important work

data. I reckon a lot of home users wont be backed up at all though so the

method above is better than nothing at all.

Tilmann Reh wrote on Fri, 08 January 2016 10:23

If you really lose the repo, all you keep is the current WC and the

history (AFAIK).

The problem I had with SVN related to losing the history when a server disk

failure took out the SVN server. I think it only kept the most recent

changes per file in the working copy so any earlier changes were lost and I

had to go back to a backup and recreate stuff from there. I could be wrong

on this though as it was many years ago now and my recollection of the

exact scenario is a little vague.

Tilmann Reh wrote on Fri, 08 January 2016 10:23

I think this applies to most/all version control systems. I didn't

check yet if it's possible to recreate former versions from that local

history - it just doesn't matter to me since I always do my backup

homework.

This is not the case with GIT though as every clone is a complete

repository with all the history, not just a working copy of the latest

version.

Best Regards,

Rachael

--

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

On 08.01.2016 11:17, Rachael wrote:

Morten Leikvoll wrote on Fri, 08 January 2016 09:46

Maybe it would be a nice feature if Eagle had some built in support for

SVN/GIT now that it's design and library files are ASCII based? Maybe they

could even implement a way to highlight differences from previous versions

right in the schematics, layout or libraries?

A graphic diff tool for sch/brd using whatever vc framework is high up

on my wish list

Apart from setting up the framework, Id like to know as little as

possible about the background processes.

On 08/01/16 10:51, Rachael wrote:

The problem I had with SVN related to losing the history when a server disk

failure took out the SVN server. I think it only kept the most recent

changes per file in the working copy so any earlier changes were lost and I

had to go back to a backup and recreate stuff from there.

But the problem there was not due to any shortcoming in SVN, but rather

due to your not having had the correct backup. The server administrator

should have maintained proper backups of the repository, just like the

admin of ANY VCS repository should. The fact that GIT redundantly

duplicates far more information than anyone should ever need is not a

substitute for proper backups, either, just a haphazard,

luck-of-the-draw possible grace-of-god skin-of-the-teeth escape you

might be lucky enough to get.

Rob Pearce wrote on Fri, 08 January 2016 12:59

But the problem there was not due to any shortcoming in SVN, but rather

due to your not having had the correct backup. The server administrator

should have maintained proper backups of the repository, just like the

admin of ANY VCS repository should.

Read my post again, we went back to the backup when we found we couldn't

get everything from the working copy.... The big issue though was the

repository in question was several Gb in size as it had a lot of data from

many developers from over many years so going back to the backups and

restoring from there was more long winded.

Rob Pearce wrote on Fri, 08 January 2016 12:59

The fact that GIT redundantly duplicates far more information than

anyone should ever need is not a substitute for proper backups, either,

just a haphazard, luck-of-the-draw possible grace-of-god

skin-of-the-teeth escape you might be lucky enough to get.

Now you're just being silly. Git stores all this information in every

cloned copy as it is designed as a DISTRIBUTED version control system. For

this purpose it works exceedingly well. I never said you should rely on

this for a backup solution, especially in a professional environment, and I

don't, but it DOES work as a rudimentary way to easily keep a backup of

your local repositories if you don't have the need or capability to do

anything better.

--

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