X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+CLT/muWqJEND2uAOF0/Y/PhdyTkW8oUY0mpT4W3dPc=;
	b=WOfuHk3xnzA3y2FJP9bEKvfrUY/yOhwnkpx4N85vSaHgCVZkK3NWaKb0KSvz3sOAue
	kUQmXQxSf76mfA+4KvEn5JeSL5zdspsb6f1WBV321DpcNrS3MsKunfB929wJPxRkLlby
	VBnNMDcbyregzN4ls805BJkeLUjeFlcwdxlzxWTLXCu+92Q6tso4XI+1dV5/+b3TEbSq
	tpyETHMkdnlqNRE/1BXwubScPwDVAQtVpdM+3pVGRYoKolb/UhmVP96vJgtTk3i1bgBu
	0zApNKIxpt2dVV9NbyDza1SW+eLDY02btNHKXtcAzOGME7jLtQbqzk48+1B40mDP9RLN
	2I3g==
MIME-Version:	1.0
In-Reply-To:	<878v7uv4gl.fsf@gmail.com>
References:	<87wqvhd4tw DOT fsf AT gmail DOT com>
	<kd21ao$j6j$1 AT ger DOT gmane DOT org>
	<20130115013756 DOT 9917 DOT qmail AT stuge DOT se>
	<CAOP4iL0yLZ-gvovCy5zCmJyjOXUUaoOB5U1+6CqcD20BM15FiQ AT mail DOT gmail DOT com>
	<50F4E4D1 DOT 3010802 AT ecosensory DOT com>
	<CAOP4iL1f=3TV5UKUjyJtpUw_5oBDxpk=5S2F=dEcUC2UYiNhVQ AT mail DOT gmail DOT com>
	<878v7uv4gl DOT fsf AT gmail DOT com>
Date:	Tue, 15 Jan 2013 10:51:47 -0800
Message-ID:	<CAOP4iL3fobzQNV5YN7kQ74L2Z2fsz1E3XJDffA1U+jBTF9qjXA@mail.gmail.com>
Subject:	Re: [geda-user] geda-skeleton-project: Lowering the cost of a
	starting a gEDA project
From:	Ouabache Designworks <z3qmtr45 AT gmail DOT com>
To:	Ben Gamari <bgamari DOT foss AT gmail DOT com>
Cc:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--f46d043bd988f5053b04d35840ae
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 15, 2013 at 7:41 AM, Ben Gamari <bgamari DOT foss AT gmail DOT com> wrote:

>
> This is what version control systems are for. Tags and branches exist
> precisely for this reason. In the case of git, one can handle the case
> of multiple source repositories with git-submodule. Other modern VCSes
> have similar facilities. There are much better tools than cp(1) for
> dealing with archival and versioning.
>
> Cheers,
>
> - Ben
>
>

Version control systems were designed by software engineers for software
engineers.  A lot of hardware design now
resembles software programming so we can use a lot of their tools BUT not
all of them. Hardware design is more complex than
software programming and not all software tools will work. Version control
is one of them.

A programmer knows that all .log and .obj files are generated  so it is
easy to set up git to ignore all of them. Cleaning them
out between runs is a simple wild card operation.

The hardware designer does not know if a verilog .v file was handcrafted
and must be checked in or generated by finiteStateMachine
tool and should not be checked in.  Setting up the ignore  and clean
functions can be done but will take a lot of effort. Using something
like lndir saves a lot of effort in the long run and doesn't break down in
the middle of a design project.


The thing to remember about VersionControl is that your design data is
probably going to live on long after the VersionControlSystem du_jour has
been dumped for the next best one.  When selecting a new one the only thing
you need to know is how to get your data and checkin logs out of
it when it comes time to move on to a newer VCS.

All VersionControlSystems will do four things:


1) Gives you an easy way to clone the entire repository. If anybody wants a
copy of your design simply point them to the repository and they are
    out of your hair.


2) Gives you an easy way to do backups.  Clone repository, update once a
day and then back that up off-site. Sleep better at night.


3) Tracks changes.  Shows all the changes made to any file along with
who,what,when and why. You only get the why if they write a descriptive
    check in message.

3) Gives you a time machine. If something is not working that you are sure
you checked last month then restore back to last month and check it again.
    If  it once worked then do a binary search to see when it broke and who
dunnit.


Beyond that they all provide various features to help developers and most
VCS wars are fought over these features. If you are smart then you will not
use any
of them because they will all complicate things when it comes time to move
your data on to the  next VCS.


John Eaton

--f46d043bd988f5053b04d35840ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Jan 15, 2013 at 7:41 AM, Ben Gam=
ari <span dir=3D"ltr">&lt;<a href=3D"mailto:bgamari DOT foss AT gmail DOT com" target=
=3D"_blank">bgamari DOT foss AT gmail DOT com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"im"><br>
</div>This is what version control systems are for. Tags and branches exist=
<br>
precisely for this reason. In the case of git, one can handle the case<br>
of multiple source repositories with git-submodule. Other modern VCSes<br>
have similar facilities. There are much better tools than cp(1) for<br>
dealing with archival and versioning.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div><br><br>Version control systems were designed by softwar=
e engineers for software engineers.=A0 A lot of hardware design now<br>rese=
mbles software programming so we can use a lot of their tools BUT not all o=
f them. Hardware design is more complex than<br>
software programming and not all software tools will work. Version control =
is one of them.<br><br>A programmer knows that all .log and .obj files are =
generated=A0 so it is easy to set up git to ignore all of them. Cleaning th=
em<br>
out between runs is a simple wild card operation.<br><br>The hardware desig=
ner does not know if a verilog .v file was handcrafted and must be checked =
in or generated by finiteStateMachine<br>tool and should not be checked in.=
=A0 Setting up the ignore=A0 and clean functions can be done but will take =
a lot of effort. Using something<br>
like lndir saves a lot of effort in the long run and doesn&#39;t break down=
 in the middle of a design project.<br><br><br>The thing to remember about =
VersionControl is that your design data is probably going to live on long a=
fter the VersionControlSystem du_jour has<br>
been dumped for the next best one.=A0 When selecting a new one the only thi=
ng you need to know is how to get your data and checkin logs out of<br>it w=
hen it comes time to move on to a newer VCS.<br><br>All VersionControlSyste=
ms will do four things:<br>
<br><br>1) Gives you an easy way to clone the entire repository. If anybody=
 wants a copy of your design simply point them to the repository and they a=
re<br>=A0=A0=A0 out of your hair.<br><br><br>2) Gives you an easy way to do=
 backups.=A0 Clone repository, update once a day and then back that up off-=
site. Sleep better at night.<br>
<br><br>3) Tracks changes.=A0 Shows all the changes made to any file along =
with who,what,when and why. You only get the why if they write a descriptiv=
e<br>=A0=A0=A0 check in message.<br><br>3) Gives you a time machine. If som=
ething is not working that you are sure you checked last month then restore=
 back to last month and check it again. <br>
=A0 =A0 If=A0 it once worked then do a binary search to see when it broke a=
nd who dunnit.<br><br><br>Beyond that they all provide various features to =
help developers and most VCS wars are fought over these features. If you ar=
e smart then you will not use any<br>
of them because they will all complicate things when it comes time to move =
your data on to the=A0 next VCS.<br><br><br>John Eaton<br><br><br><br><br><=
br>=A0<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><=
br>
<br><br><br><br><br>=A0<br>

--f46d043bd988f5053b04d35840ae--

- Raw text -