RepRap contemplating move to Launchpad
Sam Putman
consequences for the RepLab project, so here's a head's up.
http://blog.reprap.org/2010/02/broadening-reprap-participation.html
Opinions solicited in the comments of the blog. So far, commenters are
backing Git over Launchpad.
Cheers,
-Sam Putman.
Bryan Bishop
> http://blog.reprap.org/2010/02/broadening-reprap-participation.html
I braindumped:
"""
Re: branching and merging electronics and mechanical components. In
the SKDB project, they use a plain-text file to represent
relationships between components (mechanical, no electronics demo yet
though). When you make changes to these files, `diff` and other tools
are more easily able to handle those changes. CAD data is another
story. I suggest bringing up the topic here and searching the archives
there too.
Actually, come to think of it, if you want to be able to do merging
between CAD files, the best way to do this right now would be
something akin to (1) BRLCAD mged scripts and merging text files of
those scripts, (2) OpenSCAD text files (before they are compiled into
STL) which can be merged just like in code, and (3) some sort of
higher-level API that pythonOCC has been working on like in
Level2API.py. For instance, consider some python used to generate CSG
(hypothetical only). This would allow merges and changes with 'diff'
and other dvcs tools like git, hg, bzr, etc.
That's a simple quick hack to things. There's a deeper problem that
will bite you in the ass re: automatic merging. At the moment, tools
like 'diff' don't know how to merge different CAD features. For
instance, one user might have added handle bars on to a bike design,
and another user does the same, and then a third user tries to merge
the designs. That will not go over well and still requires user
intervention. Buut in the mean time, text-based CAD file specification
gives us a lot of power. :-) Cheers!
"""
John Griessen
> On Wed, Feb 24, 2010 at 11:52 AM, Bryan Bishop <kan...@gmail.com> wrote:
>> That's a simple quick hack to things. There's a deeper problem that
>> will bite you in the ass re: automatic merging.
.
.
allow the files to contain
> conflicting parts, and leave it up to the CAD program to deal with it.
Code developers don't use version control that way yet, so we cannot
expect to. During a version control merge, the person running it
is responsible for deciding if putting lines together with
other lines of code makes sense. The 2 bike handlebars merge
problem needs a human communication helper, not an automaton
that creates multiversioned CAD files. the "suppressed image" feature
in solidworks is to hard to add to CAD based on OCC without OCC
developer involvement, so it needs to be put off as a wish list item
and proceed with something that detects a conflict and helps email the
needed folks to resolve it. The practical resolution is to create
two bike versions, two bike names, and two bike docs after hitting such
a conflict.
John
Bryan Bishop
> Jason Pepas wrote:
>>> That's a simple quick hack to things. There's a deeper problem that
>>> will bite you in the ass re: automatic merging.
>>
>> conflicting parts, and leave it up to the CAD program to deal with it.
>
> Code developers don't use version control that way yet, so we cannot
> expect to. During a version control merge, the person running it
> is responsible for deciding if putting lines together with
> other lines of code makes sense. The 2 bike handlebars merge
> problem needs a human communication helper, not an automaton
> that creates multiversioned CAD files. the "suppressed image" feature
> in solidworks is to hard to add to CAD based on OCC without OCC
> developer involvement, so it needs to be put off as a wish list item
> and proceed with something that detects a conflict and helps email the
> needed folks to resolve it. The practical resolution is to create
> two bike versions, two bike names, and two bike docs after hitting such
> a conflict.
One way that I can think of to do that would be git post-commit hooks.
I don't recall if there are "merge conflict hooks". But if they do
exist, then that would be the perfect place to have it notify the user
exactly what the error is, and show the 3D models of the two
conflicting versions. I don't know about emailing the developers etc.,
mostly because merge conflicts have to be solved by the down-stream
user *before* it can be pushed to a repository.
For instance, in git, when there's a merge conflict in a text file,
there are indicators (>>>>) added with some metadata to the areas of
conflict. I suppose the user could commit this data and then ask
someone upstream to take a look at it. But committing unmerged files
is usually undesirable. Maybe this could be an exception?
Dunno.
John Griessen
> On Wed, Feb 24, 2010 at 3:01 PM, John Griessen wrote:
>>> On Wed, Feb 24, 2010 at 11:52 AM, Bryan Bishop wrote:
>> allow the files to contain
>>> conflicting parts, and leave it up to the CAD program to deal with it.
>> Code developers don't use version control that way yet, so we cannot
.
.
.
> One way that I can think of to do that would be git post-commit hooks.
> I don't recall if there are "merge conflict hooks". But if they do
> exist, then that would be the perfect place to have it notify the user
> exactly what the error is, and show the 3D models of the two
> conflicting versions. I don't know about emailing the developers etc.,
> mostly because merge conflicts have to be solved by the down-stream
> user *before* it can be pushed to a repository.
I was only thinking of communication aids for the people
doing the parts conflicting, not developers of code, and not auto,
just an available aid like sending emails about patches that the
receiver can use to commit the patch easily with git.
>
> For instance, in git, when there's a merge conflict in a text file,
> there are indicators (>>>>) added with some metadata to the areas of
> conflict.
Yeah.
I suppose the user could commit this data and then ask
> someone upstream to take a look at it.
I don't see that -- just resolve such a conflict before going ahead.
Use git to create patches of your work for others to test, resolve problems.
What does upstream mean in OpenHW context? Upstream towards the original
OpenHW publisher?
The original question was about the case of accidentally having two bike handlebars
when you try to merge work by two or more people.
It's handled in git parlance as a branch of OpenHW development where the task to
do is separate the handlebars by branching the bike project, then on branch 2 removing
one handlebar and adding the other.
Then git keeps the effort low to merge all work on other parts of the bike so both branches
stay complete and up to date.
John