=?UTF-8?B?Y2hlamlhbiIgPHhpbmNoZWppYW5AZ29vZ2xlZ3JvdXBzLmNvbT4=?=
Received: by 10.66.77.35 with SMTP id p3mr1241143paw.44.1346383305395;
Thu, 30 Aug 2012 20:21:45 -0700 (PDT)
X-BeenThere: xinchejian@googlegroups.com
Received: by 10.68.236.231 with SMTP id ux7ls9824920pbc.4.gmail; Thu, 30 Aug
2012 20:21:44 -0700 (PDT)
Received: by 10.66.85.98 with SMTP id g2mr1076244paz.37.1346383304655;
Thu, 30 Aug 2012 20:21:44 -0700 (PDT)
Received: by 10.66.85.98 with SMTP id g2mr1076243paz.37.1346383304404;
Thu, 30 Aug 2012 20:21:44 -0700 (PDT)
Return-Path: <spanner...@usabledevices.com>
Received: from m1plsmtpa01-07.prod.mesa1.secureserver.net (m1plsmtpa01-07.prod.mesa1.secureserver.net. [64.202.165.186])
by gmr-mx.google.com with ESMTP id nv4si751168pbc.2.2012.08.30.20.21.44;
Thu, 30 Aug 2012 20:21:44 -0700 (PDT)
Received-SPF: neutral (google.com: 64.202.165.186 is neither permitted nor denied by best guess record for domain of spanner...@usabledevices.com) client-ip=64.202.165.186;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 64.202.165.186 is neither permitted nor denied by best guess record for domain of spanner...@usabledevices.com) smtp.mail=spanner...@usabledevices.com
Received: from [192.168.0.102] ([58.247.141.21])
by m1plsmtpa01-07.prod.mesa1.secureserver.net with
id tFMf1j00B0TuBW201FMiNP; Thu, 30 Aug 2012 20:21:43 -0700
Message-ID: <50402DFF.40008@usabledevices.com>
Date: Fri, 31 Aug 2012 11:22:39 +0800
From: spanner888 <spanner...@usabledevices.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: xinchejian@googlegroups.com, swarmrob...@xinchejian.com
Subject: SwarmRobots have multiplied - in need of naming, version and licence
help!
Content-Type: multipart/alternative;
boundary="------------070309040905070506020604"
This is a multi-part message in MIME format.
--------------070309040905070506020604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
We now have *three different SwarmRobot hardware versions* in
development (more coming?) plus we have several older versions of the
PCB and breadboard prototypes.
There are also now *three different shields* (and many more to make!)
and the *different code to support the different SwarmBots and shields*
PLUS all of the *different versions of each hardware and software item*.
So we need some structure to help manage all of this! So please review
and tear apart and comment on the suggestions below :).
Suggestions, based on the current work for the SwarmRobot process and
motor controller PCB:
SwarmRobot-Tiny
SwarmRobot-Uno (is the motor controller on the shield?)
SwarmRobot-Sunny
For the shields we also need to indicate which Swarm robot they fit, so
I suggest:
SwarmRobot-Tiny-Shield-IR-Rx
SwarmRobot-Tiny-Shield-WallFollow-Avoid
SwarmRobot-Uno-Shield-Motor-IR-RxTx
etc
Then the code should follow similar convention to indicate which
hardware is supported.
*To manage the code should we create git branches for each variation?*
Then the other branches can choose what to merge (or can only the main
branch do that?). I have added some basic git info at the end of this
email.
How does SwarmBot instead of SwarmRobot fit, or should we keep these
names shorter and just use SR, or XCJ-SR.....?
For version numbering, I propose we start/continue v0.0x, then when
getting near a "polished" first version move to 0.x, then 1.x on first
release (eg for the Afron competition).
Finally - does anyone know what *software and hardware licences*
Xinchejian prefers to use?
The wiki says ""
Can't find anything in Xinchejian GIT.
Any suggestions?
--------------------------------------------------------------------------------------------------------
Here is some Git how to information from git - the simple guide
<http://rogerdudler.github.com/git-guide/>
"Branches are used to develop features isolated from each other. The
master branch is the "default" branch when you create a repository. Use
other branches for development and merge them back to the master branch
upon completion."
create a new branch named "feature_x" and switch to it using
| git checkout -b feature_x|
switch back to master
| git checkout master|
and delete the branch again
| git branch -d feature_x|
a branch is /not available to others/ unless you push the branch to
your remote repository
| git push origin <branch>|
||
||
update & merge
to update your local repository to the newest commit, execute
| git pull|
in your working directory to /fetch/ and /merge/ remote changes.
to merge another branch into your active branch (e.g. master), use
| git merge <branch>|
in both cases git tries to auto-merge changes. Unfortunately, this
is not always possible and results in /conflicts/. You are
responsible to merge those /conflicts/ manually by editing the files
shown by git. After changing, you need to mark them as merged with
| git add <filename>|
before merging changes, you can also preview them by using
| git diff <source_branch> <target_branch>|
--------------070309040905070506020604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
We now have <b>three different SwarmRobot hardware versions</b> in
development (more coming?) plus we have several older versions of
the PCB and breadboard prototypes.<br>
<br>
There are also now <b>three different shields</b> (and many more to
make!) and the <b>different code to support the different SwarmBots
and shields</b> PLUS all of the <b>different versions of each
hardware and software item</b>.<br>
<br>
So we need some structure to help manage all of this! So please
review and tear apart and comment on the suggestions below :). <br>
<br>
Suggestions, based on the current work for the SwarmRobot process
and motor controller PCB:<br>
<blockquote>SwarmRobot-Tiny<br>
SwarmRobot-Uno (is the motor controller on the shield?)<br>
SwarmRobot-Sunny<br>
</blockquote>
For the shields we also need to indicate which Swarm robot they fit,
so I suggest:<br>
<blockquote>SwarmRobot-Tiny-Shield-IR-Rx<br>
SwarmRobot-Tiny-Shield-WallFollow-Avoid<br>
SwarmRobot-Uno-Shield-Motor-IR-RxTx<br>
etc<br>
</blockquote>
Then the code should follow similar convention to indicate which
hardware is supported.<br>
<br>
<b>To manage the code should we create git branches for each
variation?</b> Then the other branches can choose what to merge
(or can only the main branch do that?). I have added some basic git
info at the end of this email.<br>
<br>
How does SwarmBot instead of SwarmRobot fit, or should we keep these
names shorter and just use SR, or XCJ-SR.....?<br>
<br>
<br>
For version numbering, I propose we start/continue v0.0x, then when
getting near a "polished" first version move to 0.x, then 1.x on
first release (eg for the Afron competition).<br>
<br>
Finally - does anyone know what <b>software and hardware licences</b>
Xinchejian prefers to use?<br>
<br>
<blockquote>The wiki says ""<br>
<br>
Can't find anything in Xinchejian GIT.<br>
<br>
Any suggestions?<br>
</blockquote>
<br>
<br>
--------------------------------------------------------------------------------------------------------<br>
Here is some Git how to information from <a
href="http://rogerdudler.github.com/git-guide/">git - the simple
guide</a><br>
<br>
"Branches are used to develop features isolated from each other. The
master branch is the "default" branch when you create a repository.
Use other branches for development and merge them back to the master
branch upon completion."<br>
<blockquote>create a new branch named "feature_x" and switch to it
using<br>
<code> git checkout -b feature_x</code><br>
switch back to master<br>
<code> git checkout master</code><br>
and delete the branch again<br>
<code> git branch -d feature_x</code><br>
a branch is <i>not available to others</i> unless you push the
branch to your remote repository<br>
<code> git push origin <branch></code><br>
<code></code><br>
<code></code>
<h2>update & merge</h2>
to update your local repository to the newest commit, execute <br>
<code> git pull</code><br>
in your working directory to <i>fetch</i> and <i>merge</i>
remote changes.<br>
to merge another branch into your active branch (e.g. master), use<br>
<code> git merge <branch></code><br>
in both cases git tries to auto-merge changes. Unfortunately, this
is not always possible and results in <i>conflicts</i>. You are
responsible to merge those <i>conflicts</i> manually by editing
the files shown by git. After changing, you need to mark them as
merged with<br>
<code> git add <filename></code><br>
before merging changes, you can also preview them by using<br>
<code> git diff <source_branch> <target_branch></code></blockquote>
<div class="scrollblock block-merging">
<p> </p>
</div>
<br>
</body>
</html>
--------------070309040905070506020604--
Message from discussion SwarmRobots have multiplied - in need of naming, version and licence help!
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |