[EE] Project management aids
Vitaliy
> [...] with GTDinbox as well Google Calendar,
> you may also get a project tracking system that you asked last time.
Since I've made that post, I've done more reading and reflecting on the
subject of project management (even went back and re-read the MMM), and came
to the conclusion that most project tracking software out there is not very
effective (in some cases, counter-productive). Microsoft Project in
particular seems better suited for construction-type projects, rather than
software development.
I like the "tasks pinned to a wall" PM tool that Cockburn described in his
"Agile Software Development" book (ISBN-13: 978-0201699692, pg 70-71):
-------------------
Dee Hock's VISA Story
"We decided to become our own prime contractor, farming out selected tasks
to a variety of software developers and then coordinating and implementing
results. Conventional wisdom held it to be one of the worst possible ways to
build computerized communications systems.
We rented cheap space in suburban building and dispensed with leasehold
improvements in favor of medical curtains on rolling frames for the limited
spatial separation required....
Swiftly, self-organization emerged. An entire wall became a pinboard with
every remaining day calendared across the top. Someone grabbed an unwashed
coffee cup and suspended it on a long piece of string pinned to the current
date. Every element of work to be done was listed on a scrap of paper with
the required completion date and name of the person who had accepted the
work. Anyone could revise the elements., adding tasks or revising dates,
provided that they coordinated with others affected. Everyone, at any time,
could see the picture emerge and evolve. They could see how the whole
depended on their work and how their work was connected to every other part
of the effort. Groups constantly assembled in front of the board as need and
inclination arose, discussing and deciding in continuous flow and then
dissolving as needs were met. As each task was completed, its scrap of paper
would be removed. Each day, the cup and string moved inexorably ahead.
Every day, every scrap of paper that fell behind the grimy string would find
an eager group of volunteers to undertake the work required to remove it. To
be able to get one's own work done and help another became a sought-after
privilege. Nor did anyone feel beggared by accepting help. Such Herculean
effort meant that at any time, anyone's task could fall behind and emerge on
the wrong side of the string.
Leaders spontaneously emerged and ingenuity exploded. Individuality and
diversity flourished. People astonished themselves at what they could
accomplish and were amazed at the suppressed talents that emerged in others.
Position became meaningless. Power over others became meaningless. Time
became meaningless. Excitement about doing the impossible increased, and a
community based on purpose, principle, and people arose. Individuality,
self-worth, ingenuity, and creativity flourished; and as they did, so did
the sense of belonging to something larger than self, something beyond
immediate gain and monetary gratification.
[...]
No one ever replaced the dirty string and no one washed the cup.... The
BASE-I system came up on time, under budget, and exceeded all operating
objectives"
-------------------
To paraphrase some of the ideas in the book, the primary goal of software
development is to deliver working software. Everything else should be judged
by the effect it has on the primary goal (helping or hindering the process),
not on its own merit. There's something about the "tangibility" of
whiteboards, flip charts, pinboards, and cups suspended on dirty strings,
that make them more effective than tables and graphs on computer screens.
Vitaliy
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
SM Ling
> SM Ling wrote:
> > [...] with GTDinbox as well Google Calendar,
> > you may also get a project tracking system that you asked last time.
>
> particular seems better suited for construction-type projects, rather than
> software development.
>
> I like the "tasks pinned to a wall" PM tool that Cockburn described in his
> "Agile Software Development" book (ISBN-13: 978-0201699692, pg 70-71):
>
>
> development is to deliver working software. Everything else should be
> judged
> by the effect it has on the primary goal (helping or hindering the
> process),
> not on its own merit. There's something about the "tangibility" of
> whiteboards, flip charts, pinboards, and cups suspended on dirty strings,
> that make them more effective than tables and graphs on computer screens.
>
If you have not read about GTD, you may want to it.
GTDinbox can be a simple tasked base tracking system to complement your
"postit" note system, it is not a "sophisticated" sw with super graphics,
graph, chart, or table etc. I see as a Tagging system for you to pin your
tasks to your googlemail. And the tasks are tagged, so categorise,
therefore help in searching and view them when you want.
Ling SM
Timothy J. Weber
> If you have not read about GTD, you may want to it.
>
> GTDinbox can be a simple tasked base tracking system to complement your
> "postit" note system, it is not a "sophisticated" sw with super graphics,
> graph, chart, or table etc. I see as a Tagging system for you to pin your
> tasks to your googlemail. And the tasks are tagged, so categorise,
> therefore help in searching and view them when you want.
I think I missed the earlier part of this conversation, but personally I
love Trac, an open-source system integrating tasks, version control, and
a wiki. It's especially nice if you're already using Subversion.
Lightweight yet very good at tying it all together.
--
Timothy J. Weber
http://timothyweber.org
Vitaliy
> I think I missed the earlier part of this conversation, but personally I
> love Trac, an open-source system integrating tasks, version control, and
> a wiki. It's especially nice if you're already using Subversion.
> Lightweight yet very good at tying it all together.
I find this subject very interesting. What sort of environment are you using
it in (size of team, colocated or not, any particular project development
methodologies in use).
Also, which features of Trac do you find especially useful?
Timothy J. Weber
> Timothy J. Weber wrote:
>> I think I missed the earlier part of this conversation, but personally I
>> love Trac, an open-source system integrating tasks, version control, and
>> a wiki. It's especially nice if you're already using Subversion.
>> Lightweight yet very good at tying it all together.
>
> I find this subject very interesting. What sort of environment are you using
> it in (size of team, colocated or not, any particular project development
> methodologies in use).
Right now: four team members, in three different cities on two
continents. Development methodology is my version of 'agile' - releases
on the order of 1-2 months, continual refactoring and re-assessment of
task status. Would like to have more participation from key customers,
but I've only recently taken over this particular project and it's
1980s-era technology managed by a succession of non-professionals, so
it'll be a slow process of recovery. :)
> Also, which features of Trac do you find especially useful?
I like having the integrated wiki; my rule is, if I'm going to write it
down, I write it in the wiki, and if someone asks me a question, I try
to get the answer in the wiki. It's already a useful reference after
only a few months.
I like its low-key approach to linking. Basically, any text anywhere
(including Subversion commit messages, wiki, and ticket text) becomes
liked to a Subversion revision if it's like "r142", and linked to a
ticket if it's like "#142". So it's convenient to link everything to
everything else that's relevant.
I like that it's browser-based, which practically everything is, but
still - zero install is very handy. And it seems pretty snappy.
I like that you can write reports directly in SQL - I don't have to
puzzle through somebody's complicated reporting UI just to add a "WHERE
keywords LIKE '%blah%'" or "ORDER BY" clause. But it also has a decent
web-based query interface for users who don't know SQL.
I love subscribing to the RSS feed for the project timeline. Anything
anyone else changes shows up in Thunderbird as a message, and I can
leave each message there until I've inspected the changes, then delete it.
And the community seems pretty active - lots of plugins, pretty rapid
releases, great community feel on Trac's own Trac site (which makes it
easy to see a real-world example).
The hardest part about installation wasn't really related to Trac - just
setting up SSL and getting the Subversion repository served up with the
right accounts and permissions. Putting Trac on top of that was
straightforward.
In general, it feels just right, especially for a
geographically-distributed team where more-concrete tools aren't an
option. The team members who aren't process geeks also seem to "get" it
easily, and like it.
--
Timothy J. Weber
http://timothyweber.org
Gerhard Fiedler
> Timothy J. Weber wrote:
>> I think I missed the earlier part of this conversation, but personally I
>> love Trac, an open-source system integrating tasks, version control, and
>> a wiki. It's especially nice if you're already using Subversion.
>> Lightweight yet very good at tying it all together.
I'm using a similar combination, CVSNT (version control) and Mantis (issue
tracking).
The at least one thing that so far kills SVN for me is the lack of
permission handling. When I have to bring in an occasional external
collaborator, I don't want to have to either open the complete repository
or create a separate one just for that project. How do you deal with this?
>From what Timothy describes and what a brief look at the Trac web site
shows, it seems to have a similar feature set, but presented a bit
differently.
Gerhard
Timothy J. Weber
> Vitaliy wrote:
>
>> Timothy J. Weber wrote:
>>> I think I missed the earlier part of this conversation, but personally I
>>> love Trac, an open-source system integrating tasks, version control, and
>>> a wiki. It's especially nice if you're already using Subversion.
>>> Lightweight yet very good at tying it all together.
>
> I'm using a similar combination, CVSNT (version control) and Mantis (issue
> tracking).
>
> The at least one thing that so far kills SVN for me is the lack of
> permission handling. When I have to bring in an occasional external
> collaborator, I don't want to have to either open the complete repository
> or create a separate one just for that project. How do you deal with this?
I use SSL through Apache to access SVN, and use Apache's Basic
authentication. This uses the usual Apache password file. Then when
you set up the DAV module, you add an AuthzSVNAccessFile that just looks
like this:
[groups]
dev = able, baker, charlie
[/]
* = r # Top level is world-readable, say
[/project1]
* = # no access to onlookers
@dev = rw # No
[/project2]
* = # also private
@dev = rw
another_contractor = rw # and exposed to this guy
So you can give fine-grained control over all resources. Apache
authentication is a little awkward in some respects (hard to let the
user set his own password, e.g.), but it's worked fine for me. I do
actually have several projects on this same SVN server, and Trac only
knows about one of them, and permissions are segregated.
>>From what Timothy describes and what a brief look at the Trac web site
> shows, it seems to have a similar feature set, but presented a bit
> differently.
Yes, I did look at Mantis, and I've liked it when I've used it as a
casual submitter of bugs to open source sites. The Subversion and wiki
integration probably were what made me go for Trac instead for this
project. Well, and I liked Trac's visual design more, which shouldn't
influence me but does. :)
--
Timothy J. Weber
http://timothyweber.org
Gerhard Fiedler
>> From what Timothy describes and what a brief look at the Trac web site
>> shows, it seems to have a similar feature set, but presented a bit
>> differently.
>
> Yes, I did look at Mantis, and I've liked it when I've used it as a
> casual submitter of bugs to open source sites. The Subversion and wiki
> integration probably were what made me go for Trac instead for this
> project. Well, and I liked Trac's visual design more, which shouldn't
> influence me but does. :)
I had a better look at it, and I liked it, too. Pretty neat, the wiki
integration, and the timeline. Sadly I'd have to write a cvsnt plugin if I
wanted to use it (and so far it doesn't make me want to switch version
control systems :)
The next version of Mantis has wiki integration also. We'll see...
Gerhard
Timothy J. Weber
> integration, and the timeline. Sadly I'd have to write a cvsnt plugin if I
> wanted to use it (and so far it doesn't make me want to switch version
> control systems :)
I hear that! When I went looking for bug tracking, "works with my
existing version control" was a non-negotiable requirement.
(Though Subversion has some things CVS doesn't: atomic multi-file
commits, file renaming, ... well, you weren't asking that, though. :)
> The next version of Mantis has wiki integration also. We'll see...
I'd be interested to hear what you think of it.
--
Timothy J. Weber
http://timothyweber.org
Gerhard Fiedler
> (Though Subversion has some things CVS doesn't: atomic multi-file
> commits, file renaming, ... well, you weren't asking that, though. :)
I was talking about CVSNT. Many people mistake it for "CVS for Windows".
Even though that's how it all started, this is distant past now. CVSNT runs
on many platforms, including most *x flavors, and while the repository is
still based on a form of RCS files, it is quite far away from plain CVS and
has a number of features that CVS doesn't have. And possibly some that SVN
doesn't have either... :)
It has atomic checkouts, file renaming (since you mentioned those two),
rather fine-grained ACLs (including on branches, so you can have a
development branch for all devs but not everybody can commit to the
production branch etc), exclusive editing for non-mergeable files (which is
something I need) and merge points (which is quite handy for simple
branching).
>> The next version of Mantis has wiki integration also. We'll see...
>
> I'd be interested to hear what you think of it.
I'll follow up on this when I updated my server and made some experiences.
Gerhard
Timothy J. Weber
> Timothy J. Weber wrote:
>
>> (Though Subversion has some things CVS doesn't: atomic multi-file
>> commits, file renaming, ... well, you weren't asking that, though. :)
>
> I was talking about CVSNT. Many people mistake it for "CVS for Windows".
> Even though that's how it all started, this is distant past now. CVSNT runs
> on many platforms, including most *x flavors, and while the repository is
> still based on a form of RCS files, it is quite far away from plain CVS and
> has a number of features that CVS doesn't have. And possibly some that SVN
> doesn't have either... :)
Ah! You're right, I was assuming it was CVS for Windows. Good to know.
> It has atomic checkouts, file renaming (since you mentioned those two),
> rather fine-grained ACLs (including on branches, so you can have a
> development branch for all devs but not everybody can commit to the
> production branch etc), exclusive editing for non-mergeable files (which is
> something I need) and merge points (which is quite handy for simple
> branching).
I *think* Subversion has all those, FWIW (though I'm not sure what merge
points are). But still good to know.
>>> The next version of Mantis has wiki integration also. We'll see...
>> I'd be interested to hear what you think of it.
>
> I'll follow up on this when I updated my server and made some experiences.
Thanks!
--
Timothy J. Weber
http://timothyweber.org
Chris Smolinski
antenna) to it, through a large value resistor, to turn it into a
high impedance voltmeter, and I move a charged object close to the
wire, and the meter reads negative current, does that mean the object
is negatively charged, or is it positively charged, and it induced a
negative voltage/current?
--
---
Chris Smolinski
Black Cat Systems
http://www.blackcatsystems.com
David VanHorn
> If I have an electrometer, and connect a wire (acting as a sense
> antenna) to it, through a large value resistor, to turn it into a
> high impedance voltmeter, and I move a charged object close to the
> wire, and the meter reads negative current, does that mean the object
> is negatively charged, or is it positively charged, and it induced a
> negative voltage/current?
I'm not sure I understand the test setup here.
Dosen't an electrometer read voltage out of the gate?
Putting a resistor in parallel with the voltmeter gives you a current
meter, indirectly, in that you can measure voltage across the known
resistance. In your case though, you may be trying to count
electrons.
Chris Smolinski
>> If I have an electrometer, and connect a wire (acting as a sense
>> antenna) to it, through a large value resistor, to turn it into a
>> high impedance voltmeter, and I move a charged object close to the
>> wire, and the meter reads negative current, does that mean the object
>> is negatively charged, or is it positively charged, and it induced a
>> negative voltage/current?
>
>I'm not sure I understand the test setup here.
>
>Dosen't an electrometer read voltage out of the gate?
>Putting a resistor in parallel with the voltmeter gives you a current
>meter, indirectly, in that you can measure voltage across the known
>resistance. In your case though, you may be trying to count
>electrons.
An electrometer is a current measuring device, I've put a resistor in
series with the input, so that it is, in effect, measuring voltage.
--
---
Chris Smolinski
Black Cat Systems
http://www.blackcatsystems.com
Gerhard Fiedler
>> It has atomic checkouts, file renaming (since you mentioned those two),
>> rather fine-grained ACLs (including on branches, so you can have a
>> development branch for all devs but not everybody can commit to the
>> production branch etc), exclusive editing for non-mergeable files
>> (which is something I need) and merge points (which is quite handy for
>> simple branching).
>
> I *think* Subversion has all those, FWIW (though I'm not sure what merge
> points are). But still good to know.
Yes, I thought it didn't have anything like access control, but you showed
me something that does that. But I don't think this works on a branch
level, at least not the way you set it up.
Similarly with the binary files... how do you handle, say, CAD files in the
repository?
Merge points are about the following... Say you have a main (stable)
branch, and develop a few features on separate branches off it. (May be
different developers, or not; doesn't matter.) If those feature branches
take a while, you want to regularly merge in the changes on the stable
branch. Merge points mean that the system remembers when you did the last
merge from the stable branch, so you don't have to. You just issue repeated
merge commands, and it always picks up from where you merged last.
Gerhard
Timothy J. Weber
> Timothy J. Weber wrote:
>
> me something that does that. But I don't think this works on a branch
> level, at least not the way you set it up.
Sure. It's just that, in Subversion, branches are normally placed in a
different path, like this:
/myproject
/branches
/newfeature
/tags
/release1.0
/trunk
So I think you could assign different permissions to each of those
locations without a problem.
> Similarly with the binary files... how do you handle, say, CAD files in the
> repository?
Binary files don't require anything special in Subversion... they're
diffed using a binary diff algorithm, and the binary diff is what's
stored and transmitted.
Is that what you mean?
> Merge points are about the following... Say you have a main (stable)
> branch, and develop a few features on separate branches off it. (May be
> different developers, or not; doesn't matter.) If those feature branches
> take a while, you want to regularly merge in the changes on the stable
> branch. Merge points mean that the system remembers when you did the last
> merge from the stable branch, so you don't have to. You just issue repeated
> merge commands, and it always picks up from where you merged last.
Hm... I don't do that a lot, so I'm not sure... but Subversion
lets/makes you "resolve" changes against a given revision before
committing them, and I think it does remember what you last resolved to.
So I think you can resolve but not commit, and then resolving again
later will do what you're talking about.
--
Timothy J. Weber
http://timothyweber.org
David VanHorn
> An electrometer is a current measuring device, I've put a resistor in
> series with the input, so that it is, in effect, measuring voltage.
http://en.wikipedia.org/wiki/Electrometer
This seems to indicate that it's a voltage device, but at super high
impedances, it does all get kinda fuzzy.
David VanHorn
against the meter's resistance plus the added series resistance.
Chris Smolinski
>against the meter's resistance plus the added series resistance.
Yes indeed it is. My question was whether the polarity of the
current/voltage is equal or opposite to that of the charge of the
object brought close to the sense wire.
--
---
Chris Smolinski
Black Cat Systems
http://www.blackcatsystems.com
Gerhard Fiedler
> Sure. It's just that, in Subversion, branches are normally placed in a
> different path, like this:
Ah... makes sense. Interesting... Just to illustrate how difficult it is to
compare the features without an intimate knowledge of all involved systems
:)
>> Similarly with the binary files... how do you handle, say, CAD files in
>> the repository?
>
> Binary files don't require anything special in Subversion... they're
> diffed using a binary diff algorithm, and the binary diff is what's
> stored and transmitted.
>
> Is that what you mean?
No, I mean something different. It's actually not the quality of being
binary, it's the quality of being non-mergeable. There are mergeable binary
files (if you have the proper tools) and there are text files that have a
structure that's so complex and/or are generated automatically that they
are functionally non-mergeable. I'm talking here about the non-mergeable
files of either type.
If you have such files in the repo and potentially different people working
on them, it's very handy to have the repo enforce that always only one is
working on them.
>> Merge points are about the following... [...]
> Hm... I don't do that a lot, so I'm not sure... but Subversion lets/makes
> you "resolve" changes against a given revision before committing them,
> and I think it does remember what you last resolved to. So I think you
> can resolve but not commit, and then resolving again later will do what
> you're talking about.
What I'm talking about is something similar to what is in the svn roadmap
as "merge tracking".
Gerhard
Gerhard Fiedler
>>If it's really a current meter, then the voltage is found by ohm's law
>>against the meter's resistance plus the added series resistance.
>
> Yes indeed it is. My question was whether the polarity of the
> current/voltage is equal or opposite to that of the charge of the
> object brought close to the sense wire.
I would start with thinking that when you bring a negative charge to the
sense wire, it "pushes" electrons away and through the meter, and vice
versa for a positive charge.
So due to the inversion of electron movement compared to the current
direction standard, you'd have a positive current flowing into the meter
for a positive charge.
Gerhard
Timothy J. Weber
> Ah... makes sense. Interesting... Just to illustrate how difficult it is to> compare the features without an intimate knowledge of all involved systems
> :)
Indeed. Sounds like culture. :)
> I'm talking here about the non-mergeable
> files of either type.
>
> If you have such files in the repo and potentially different people working
> on them, it's very handy to have the repo enforce that always only one is
> working on them.
Got it. This is called a "lock" in Subversion, and you can specify that
a particular file is made read-only if you don't have a lock.
>>> Merge points are about the following... [...]
>
>> Hm... I don't do that a lot, so I'm not sure... but Subversion lets/makes
>> you "resolve" changes against a given revision before committing them,
>> and I think it does remember what you last resolved to. So I think you
>> can resolve but not commit, and then resolving again later will do what
>> you're talking about.
>
> What I'm talking about is something similar to what is in the svn roadmap
> as "merge tracking".
Ah... (reading) I see - it *doesn't* currently remember what you've
resolved. Looks like an interesting feature set.
I guess I never spend significant time out on branches... I wonder why.
--
Timothy J. Weber
http://timothyweber.org
Luis Moreira
I use Orcad 10.5 at work, and I am on the process of laying down a board
that has several TQFP parts. In particular I have a TQFP 144 package
that when I decided to check the footprint in the Orcad layout library
seems odd...
When I compared the part's pin width and length, it is larger than the
footprint's pads size. I always thought that it would be the other way
around but then looking at some example boards from several
manufacturers it seems, as the pin density increases, they make the pads
the same dimensions as the pin or smaller.
I would be grateful for your advice and if you have any info on
standards it would be great.
Best regards
Luis
Peter P.
>
> >If it's really a current meter, then the voltage is found by ohm's law
> >against the meter's resistance plus the added series resistance.
>
> Yes indeed it is. My question was whether the polarity of the
> current/voltage is equal or opposite to that of the charge of the
> object brought close to the sense wire.
Think of the assembly as o capacitor. The object is one armature and the sense
electrode the other. If, and only if, there is a potential difference between
the armatures, the act of moving them towards each other will affect the voltage
on the sense electrode vs. ground. The direction of change of the voltage
depends on the respecitve polarity of the charges on the object and on the sense
plate. E.g. using series capacitor model:
Far away: Testobj --| C1 |-Sense-| C2 |-Gnd
Close in: Testobj -------| C1' |-Sense-| C2 |-Gnd
Assume the charge on Sense is constant and small and the charge on Testobj is
large, and derive the equation for Vsense change when C1 changes. Note that you
have the case of the electrophorus, in reverse.
hope this helps,
Peter P.
Gerhard Fiedler
> I use Orcad 10.5 at work, and I am on the process of laying down a board
> that has several TQFP parts. In particular I have a TQFP 144 package
> that when I decided to check the footprint in the Orcad layout library
> seems odd...
> When I compared the part's pin width and length, it is larger than the
> footprint's pads size. I always thought that it would be the other way
> around but then looking at some example boards from several
> manufacturers it seems, as the pin density increases, they make the pads
> the same dimensions as the pin or smaller.
I'm not sure there is a single rule. I think for one it depends on the
soldering process (wave, reflow, hand). Wave needs some concern about the
direction of the wave, shadows and other things. Hand soldering may need
the pads to stay out more.
Then there are a few things that sometimes are just different, maybe due to
taste :) I just saw a footprint for medium density chips from I think
Philips, where they had the outer pads a bit wider than the others. I'm not
sure what the exact purpose is, but maybe it facilitates something. WRT the
width in general, I think with higher densities, you can't make the pad
much wider than the pin, because of the necessary clearance: it doesn't
help you much to have a nice wide pad if the next one is just a (thin) hair
away :)
Gerhard
Gerhard Fiedler
> Indeed. Sounds like culture. :)
Version control is culture -- programming culture :)
> Got it. This is called a "lock" in Subversion, and you can specify that
> a particular file is made read-only if you don't have a lock.
Apparently svn has come quite some ways since I last looked at it. It seems
that most of my "must have"s and "want have"s are there now -- but of
course that's by far not enough to switch :)
Thanks for the info about svn. I appreciate that. It's all stored away in
some corner of my brain for possible future use...
> I guess I never spend significant time out on branches... I wonder why.
My experience is that there is a bit of an entry hurdle to branching, and
most people only make the step when they have to. At least that was the
case with me. But ever since, I'm using it quite a bit; it's a very useful
tool. How often do you want to just try something out? Put it on a branch,
and even if you don't use it now, it's there, for later use. Or the typical
case: I have a stable branch for a firmware and a board that's out in a
product. I'm working on an updated board, and there are some changes to the
firmware related to the new board -- but that board is not yet in
production. In the meantime, the client wants some changes to the
production firmware. With branches, that works nicely in parallel and comes
all together when the time is ripe.
Gerhard
Peter Todd
Hash: SHA1
On Thu, Aug 23, 2007 at 10:47:42PM -0400, Timothy J. Weber wrote:
> >>> Merge points are about the following... [...]
> >
> >> Hm... I don't do that a lot, so I'm not sure... but Subversion lets/makes
> >> you "resolve" changes against a given revision before committing them,
> >> and I think it does remember what you last resolved to. So I think you
> >> can resolve but not commit, and then resolving again later will do what
> >> you're talking about.
> >
> > What I'm talking about is something similar to what is in the svn roadmap
> > as "merge tracking".
>
> Ah... (reading) I see - it *doesn't* currently remember what you've
> resolved. Looks like an interesting feature set.
>
> I guess I never spend significant time out on branches... I wonder why.
You should give one of the distributed revision control systems, like
git or monotone, a try... I use monotone myself, and make very heavy
usage of branches. The key thing is that it handles merges very well.
For instance today I was finishing up the firmware for the 1.1 version
of my Alternace Pace clock. Now for some background that code goes on
the branch io.pkt.art.alternate-pace.pcb.1.1 When I started working on
the project everything went in just plain alternate-pace.
A key part of this though is I have yet another branch called
io.pkt.meta.example, and under it is branches like
io.pkt.meta.example.hard.elec.geda, for gEDA electrical development and
io.pkt.meta.example.firm.pic.sdcc.pk2.18f1220, for SDCC-based C
programming, that branch being for the 18f1220
These are all branches with very simple templates, for instance the sdcc
ones have my Makefiles all setup the way I like them and include the
usual basic structure of a PIC program.
To start a new project I pick one of those branches and simply derive my
new branch off of it. IIRC when I started alternate-pace I derived it
from io.pkt.meta.example and started writing preliminary notes. After
awhile I was ready to start working on the electrical schematic, so I
typed:
mtn propegate io.pkt.meta.example.hard.elec.geda \
io.pkt.art.alternate-pace
Which merged everything "new" from the geda branch to alternate-pace, in
that case added a hard/ directory structure with gEDA stuff in it. A bit
later I'd done my PCB, so I was ready to start working on the firmware.
mtn propegate io.pkt.meta.example.firm.pic.sdcc.pk2.18f1220 \
io.pkt.art.alternate-pace
During that process multiple times I found little issues with my
Makefile setup and what not. So I'd fix them in the underlying
example.firm.pic.sdcc branches, then propegate the changes to
alternate-pace and a few other branches.
Also during this time I started a new project, meter-clock. Both of them
were clocks, so large parts of my schematic and firmware could be
shared. So I branches meter-clock off of alternate-pace.
Well, actually, that's not quite true, I started it independently at
first, and much later did some magic to branch them... but that's way
beyond the scope of this email. :)
Anyway point being I was able to easilly modify the alternate-pace code
into my meter-clock. But yet, much later after finishing 1.0 of both
projects, now I'm onto 1.1 and monotone is smart enough that today I was
able to use the pluck command to take some major changes I did to the
eeprom code in meter-clock, and have it merged over to the 1.1 version
of the alternate-pace firmware. Later on I can do the same thing with
the 1.0 firmware should I need to backport anything. The merging
software "just works", beats me how it does it, but it's incredibly
smart at figuring out how to merge text-based source code.
I used to be a CVS guy for years, then subversion for a few months, but
these new revision control systems are just mind-bending in how they
make you rethink how you work. What's so neat is that a branch, instead
of being a different version of software, stable vs. devel, can be a
*module* shared between multiple, completely different, projects.
Merging is just so good now that it's a completely painless operation,
and you can merge between completely arbitrary points in history, so
long as the two sides of the merge have a common ancestor somewhere it
works.
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGztE93bMhDbI9xWQRAtzXAKCxiagFoCF6hSLVfEuj9v1xk5Dz7QCgjNyh
k+CB2ddBGIoy5+CkDJruglQ=
=RLjf
-----END PGP SIGNATURE-----
Brooke Clarke
There's a very simple electrometer circuit at:
http://amasci.com/emotor/chargdet.html
and at the bottom of this page are links to a number of other pages with simple
DIY electrostatic test equipment including this one:
http://www.ece.rochester.edu/~jones/demos/ahern.html
Moving Charge Sensor
that has a table at the bottom of the page relating the object charge polarity
and direction of movement to the output polarity indication.
--
Have Fun,
Brooke Clarke
http://www.PRC68.com
http://www.precisionclock.com
Timothy J. Weber
> Timothy J. Weber wrote:
>
>> Indeed. Sounds like culture. :)
>
> Version control is culture -- programming culture :)
Agreed. Now, can we somehow define all culture as version control??
> Apparently svn has come quite some ways since I last looked at it. It seems
> that most of my "must have"s and "want have"s are there now -- but of
> course that's by far not enough to switch :)
Of course! If it's only as-good-as what you're using now that would be
a lot of time and effort for not much reward.
>> I guess I never spend significant time out on branches... I wonder why.
>
> My experience is that there is a bit of an entry hurdle to branching, and
> most people only make the step when they have to. At least that was the
> case with me. But ever since, I'm using it quite a bit; it's a very useful
> tool. How often do you want to just try something out? Put it on a branch,
> and even if you don't use it now, it's there, for later use. Or the typical
> case: I have a stable branch for a firmware and a board that's out in a
> product. I'm working on an updated board, and there are some changes to the
> firmware related to the new board -- but that board is not yet in
> production. In the meantime, the client wants some changes to the
> production firmware. With branches, that works nicely in parallel and comes
> all together when the time is ripe.
I do use them in both those ways... just not very often. Maybe I still
have the scars from the old sccs days when version control was
coal-fired and branching required actual twigs as part of the incantation...
--
Timothy J. Weber
http://timothyweber.org
Timothy J. Weber
>> I guess I never spend significant time out on branches... I wonder why.
>
> You should give one of the distributed revision control systems, like
> git or monotone, a try...
> I used to be a CVS guy for years, then subversion for a few months, but
> these new revision control systems are just mind-bending in how they
> make you rethink how you work. What's so neat is that a branch, instead
> of being a different version of software, stable vs. devel, can be a
> *module* shared between multiple, completely different, projects.
> Merging is just so good now that it's a completely painless operation,
> and you can merge between completely arbitrary points in history, so
> long as the two sides of the merge have a common ancestor somewhere it
> works.
I don't think I totally get it, but thanks for the description; it's
definitely an interesting idea and I'll put it on the "to explore" list.
I think it may be a significant difference that I spend at least as much
time with projects that have well over 100,000 lines of code as with
ones that are a few files and run on an 8 KB chip. In that milieu,
creating a new project is something that happens rarely, but sharing a
piece of code with another person is common - so I think that may be
better suited to conventional refactoring into documented modules with
clean interfaces than to reuse by branching. But maybe that's because I
haven't seen what you're doing!
Thanks.
--
Timothy J. Weber
http://timothyweber.org
Peter Todd
Hash: SHA1
On Fri, Aug 24, 2007 at 09:39:09PM -0400, Timothy J. Weber wrote:
> I don't think I totally get it, but thanks for the description; it's
> definitely an interesting idea and I'll put it on the "to explore" list.
>
> I think it may be a significant difference that I spend at least as much
> time with projects that have well over 100,000 lines of code as with
> ones that are a few files and run on an 8 KB chip. In that milieu,
> creating a new project is something that happens rarely, but sharing a
> piece of code with another person is common - so I think that may be
> better suited to conventional refactoring into documented modules with
> clean interfaces than to reuse by branching. But maybe that's because I
> haven't seen what you're doing!
Well, you can always get yourself a copy of monotone, and grab a copy of
my publically available monotone repository... :)
Bear in mind I'm still working on how to best make use of my setup... I
think the key idea is that if merging is really easy, branches can
become a "feature", rtc chip, debugging, rather than a "version" or
"type", ie, stable, devel.
Documented modules are all nice and well, but it's quite tough to have
one of those documented modules be "the build system" But if one of the
"feature" branches is "the build system" then keeping it up to date, and
merging it into project branches becomes possible.
Now my idea of uses branches instead of software libraries is pretty
uncommon, if not completely new. And there are some problems with it in
terms of day-to-day usability. However from what I can see the branches
as features concept is used a lot in big projects useing good revision
control. Monotone development itself has dozens of branches for various
experimental, and not so experimental, features. More importantly, if
someone is working on supporting foo, they can get initial support for
foo done, merge it into the mainline, and they continue working on foo
some more. Merges can go both ways, to update foo from the mainline, and
the mainline from foo, and this process can go on indefinetely. Foo
could be a really small feature too, but the process is easy enough that
it's still doable.
Also importantly, why does it have to merge into the mainline? It's
quite possible for changes to foo to be merged into the bar feature
which in turn is merged into someone's specialty, "customer custom 1.5b
firmware fixes" Now say along the line foo is also merged into the
mainline. Well when mainline changes are propegated into that custom
1.5b firmware fixes, on Monotone nothing bad happens. CVS can't even
*begin* to do that, let alone do it without getting very confused as to
why changes are being applied twice.
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG0Kqx3bMhDbI9xWQRAsPeAJ9JjIq1FhRYoIBtoTpGZRkTurlQkACgj4v7
PIoBKnpMYt1sfAnS5V783kc=
=GYsU
-----END PGP SIGNATURE-----
Timothy J. Weber
interesting! :) I will ponder while traveling and maybe give your repo
a look when I return.
--
Timothy J. Weber
http://timothyweber.org
Peter Todd
Hash: SHA1
On Sun, Aug 26, 2007 at 09:57:38AM -0400, Timothy J. Weber wrote:
> I'm heading out of town in a few minutes - but this is blasphemous and
> interesting! :) I will ponder while traveling and maybe give your repo
> a look when I return.
Blasphemous 'eh? What can I say, I'm honored! :)
That said if anyone does take a look at that repository... To make sense
of it, you're best bet is to get the monotone-viz program, which shows
you how the different revisions relate graphically. It makes pretty, if
frighteningly complex, pictures too!
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG0dRZ3bMhDbI9xWQRArQQAJ9Y0AgjlHHXdm46TSadUheNT18TsACgpEDF
Hr+eY8fybajunvB3hRYQ9lw=
=Avy+
-----END PGP SIGNATURE-----
Gerhard Fiedler
> That said if anyone does take a look at that repository... To make sense
> of it, you're best bet is to get the monotone-viz program, which shows
> you how the different revisions relate graphically. It makes pretty, if
> frighteningly complex, pictures too!
Do you have any links to documentation of how the monotone merge works
differently from e.g. cvs merge?
Gerhard
Peter Todd
Hash: SHA1
On Mon, Aug 27, 2007 at 10:28:18AM -0300, Gerhard Fiedler wrote:
> Peter Todd wrote:
>
> > That said if anyone does take a look at that repository... To make sense
> > of it, you're best bet is to get the monotone-viz program, which shows
> > you how the different revisions relate graphically. It makes pretty, if
> > frighteningly complex, pictures too!
>
> Do you have any links to documentation of how the monotone merge works
> differently from e.g. cvs merge?
I took a look around and couldn't find anything directly comparing the
two. The best practices stuff on the wiki are interesting though:
http://www.venge.net/mtn-wiki/DaggyFixes
I make very extensive usage of the Daggy idea, probably more so than is
actually needed given how simple my projects are.
Here's another one:
http://www.venge.net/mtn-wiki/ZipperMerge
That sort of ability is really how I managed to pull off stunts like
merging almost completely different projects together. Going
incrementally is very easy.
Another good reference is the comparison the FreeBSD project did between
a number of different RCS systems:
http://wiki.freebsd.org/VersionControl
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG1esz3bMhDbI9xWQRAiVOAKCjWl7FpKC7TUgNy4c/5edUXlr0sQCcCTBP
aLf8jFv4JgjIjWyC2wX39ps=
=TRXD
-----END PGP SIGNATURE-----
Gerhard Fiedler
>>> That said if anyone does take a look at that repository... To make
>>> sense of it, you're best bet is to get the monotone-viz program, which
>>> shows you how the different revisions relate graphically. It makes
>>> pretty, if frighteningly complex, pictures too!
>>
>> Do you have any links to documentation of how the monotone merge works
>> differently from e.g. cvs merge?
>
> I took a look around and couldn't find anything directly comparing the
> two. The best practices stuff on the wiki are interesting though:
Thanks for looking this up. Interesting thoughts. I think the main
difference to CVSNT is the "lighter weight" of branches. On most smaller
projects (up to 50 or 100 files) the increased weight of the branches
doesn't make a lot of difference, though; I create a branch on such a
project in a second or two. Documenting the branch or the tags (for cherry
picking) takes much longer -- and is needed in either case :)
So I think that monotone and similar light-weight branching systems
probably add a lot to make such practices more known, and make them better
worked out in their strengths and weaknesses, but I don't think that you
can't take advantage of these techniques with the more traditional version
control systems.
(Note that CVSNT != CVS. CVS had a feature stop many years ago, while CVSNT
is in constant development.)
Gerhard
Peter Todd
Hash: SHA1
On Wed, Aug 29, 2007 at 10:51:34PM -0300, Gerhard Fiedler wrote:
> > I took a look around and couldn't find anything directly comparing the
> > two. The best practices stuff on the wiki are interesting though:
>
> Thanks for looking this up. Interesting thoughts. I think the main
> difference to CVSNT is the "lighter weight" of branches. On most smaller
> projects (up to 50 or 100 files) the increased weight of the branches
> doesn't make a lot of difference, though; I create a branch on such a
> project in a second or two. Documenting the branch or the tags (for cherry
> picking) takes much longer -- and is needed in either case :)
Mind you, remember that creating branches isn't the important part,
*merging* branches is. It's the merge that needs to be completely
painless.
> So I think that monotone and similar light-weight branching systems
> probably add a lot to make such practices more known, and make them better
> worked out in their strengths and weaknesses, but I don't think that you
> can't take advantage of these techniques with the more traditional version
> control systems.
Well you know Linux, up untill Linus invented git, was handled with
nothing more than patch and a bunch of directories. Yet that was
revision control and used many of the same concepts as git now does.
monotone and friends just makes things easier for the most part.
Although that said, stuff like server-less distributed development,
which both monotone and git support, can be very hard to do by
hand and next to impossible when you're using a single server model rcs
system.
One thing to think about, which may not have been clear from that page,
is that a branch can have multiple heads to it. IE, even if you have
only one branch in a project, it can essentially be split into multiple
different branches. That also means that you don't get the enforced
"merge before checkin" problem that happens with a lot of revision
control systems. Here's a common sequence of events that shows that:
pete@inept:/tmp/test$ cat foo
loo
pete@inept:/tmp/test$ vim foo
pete@inept:/tmp/test$ cat foo
loo
you
pete@inept:/tmp/test$ mtn ci
mtn: beginning commit on branch 'test'
mtn: committed revision a5705343748b44c784bbe1676d2dcdc42ad35a93
New revision.
pete@inept:/tmp/test$ mtn up -r 546d89a93ee31cbeddc8cf7e315af26e6b3e0f2c
mtn: selected update target 546d89a93ee31cbeddc8cf7e315af26e6b3e0f2c
mtn: modifying foo
mtn: updated to base revision 546d89a93ee31cbeddc8cf7e315af26e6b3e0f2c
Updating to a revision just behind the one we checked in. (revision
found by copy/paste from mtn log)
pete@inept:/tmp/test$ cat foo
loo
pete@inept:/tmp/test$ vim foo
pete@inept:/tmp/test$ cat foo
joo
loo
pete@inept:/tmp/test$ mtn ci
mtn: beginning commit on branch 'test'
mtn: committed revision 8ecbf3a26a7cf9b3ef29a62a21f36856fbd622b5
mtn: note: this revision creates divergence
mtn: note: you may (or may not) wish to run 'mtn merge'
monotone is warning us that we just created a new head on the branch by
checking in that revision, based off of an older one.
pete@inept:/tmp/test$ mtn heads
mtn: branch 'test' is currently unmerged:
8ecbf3a26a7cf9b3ef29a62a21f36856fbd622b5 pe...@petertodd.org
2007-08-30T12:10:03
a5705343748b44c784bbe1676d2dcdc42ad35a93 pe...@petertodd.org
2007-08-30T12:09:41
The two heads.
pete@inept:/tmp/test$ mtn merge
mtn: 2 heads on branch 'test'
mtn: [left] 8ecbf3a26a7cf9b3ef29a62a21f36856fbd622b5
mtn: [right] a5705343748b44c784bbe1676d2dcdc42ad35a93
mtn: [merged] 8ad80692ff61e530e8e3eff64b10bbf7c03b7947
mtn: note: your workspaces have not been updated
Merging, in this case the merge could be done automatically, in other
cases another program, like xxdiff, will pop up to help you resolve the
merge.
pete@inept:/tmp/test$ mtn up
mtn: updating along branch 'test'
mtn: selected update target 8ad80692ff61e530e8e3eff64b10bbf7c03b7947
mtn: modifying foo
mtn: updated to base revision 8ad80692ff61e530e8e3eff64b10bbf7c03b7947
pete@inept:/tmp/test$ cat foo
joo
loo
you
Finally our new revision. The merge could happen automatically because
the first revisiona added "you" after "loo" and the second added "joo"
before "loo" Both operations that can be done independently.
Still, I haven't used CVSNT, it may very well have the same kind of
feature set.
> (Note that CVSNT != CVS. CVS had a feature stop many years ago, while CVSNT
> is in constant development.)
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG1rZ63bMhDbI9xWQRAjgpAKCturCE0pn69M2wW1vMiIz6/bm2cwCcDH58
j6n2LnoblKd/caBtuQAH9Vc=
=kHCB
-----END PGP SIGNATURE-----
Gerhard Fiedler
> Peter Todd wrote:
>
>>>> That said if anyone does take a look at that repository... To make
>>>> sense of it, you're best bet is to get the monotone-viz program, which
>>>> shows you how the different revisions relate graphically. It makes
>>>> pretty, if frighteningly complex, pictures too!
>>>
>>> Do you have any links to documentation of how the monotone merge works
>>> differently from e.g. cvs merge?
>>
>> I took a look around and couldn't find anything directly comparing the
>> two. The best practices stuff on the wiki are interesting though:
>
> Thanks for looking this up. Interesting thoughts. I think the main
> difference to CVSNT is the "lighter weight" of branches.
On more reading, the ability to create a branch on commit (as opposed to
creating it before editing) seems to be one thing that makes this easier to
use for the "happy branching" style of development you're talking about.
I'll have to try, but I think a script of some sort can do this with
CVS/CVSNT/SVN repos also. This would definitely be helpful in some
situations, especially when trying to use some of the techniques these docs
describe.
One thing I was wondering, and the docs I've read didn't touch this. Say
you have revisions A, B, and so on through G implementing several features.
Now you do some cherry picking and merge into a branch R the
revisions/features D and E. The branch R advances with other changes, and
at a later point you decide that you want more of these features. You
forget that you already merged D and E, and just merge B through G into R.
For all I know, on CVS/CVSNT/SVN, this would create merge conflicts on the
places where D and E were merged in but modified (which often is needed
when merging in), as the system has no way of knowing that the modification
means the same thing as the original and is just necessary to integrate the
original -- and they are also not smart enough to exclude the changesets D
and E from the merge (because they already have been merged before).
How's that in monotone? Does it remember that D and E have been merged in
before and skips them when you tell it to merge B through G?
Thanks,
Gerhard Fiedler
> Mind you, remember that creating branches isn't the important part,
> *merging* branches is. It's the merge that needs to be completely
> painless.
Whether merging is painless or not depends mostly on the code changes, and
that's largely independent of any system. I'd say that managing the
branches is the most important part -- which may have an influence on how
easy merging goes. See my other post (just recently) with the question
about an example where a "smart" exclusion of prior merged code could help
a lot.
> One thing to think about, which may not have been clear from that page,
> is that a branch can have multiple heads to it. IE, even if you have
> only one branch in a project, it can essentially be split into multiple
> different branches.
That's not different with any of CVS, CVSNT or SVN AFAIK. You always can
branch a branch, ad (almost) infinitum. And you can merge in from arbitrary
branches. It's the managing of these branches and their relationships
that's the challenge.
> That also means that you don't get the enforced "merge before checkin"
> problem that happens with a lot of revision control systems.
If you work with branches, there's no "merge before checkin" problem.
That's what I wrote about the creating of a branch on the fly on checkin in
my other post. I think simplifying this is one of the major factors in
making this simpler in monotone, but that's not something that's impossible
with CVS/CVSNT/SVN. I'd have to try it, but I think a script can do that
(creating a branch on the fly, with code that's already edited).
> Here's a common sequence of events that shows that:
>
> pete@inept:/tmp/test$ cat foo
> loo
> pete@inept:/tmp/test$ vim foo
> pete@inept:/tmp/test$ cat foo
> loo
> you
> pete@inept:/tmp/test$ mtn ci
> mtn: beginning commit on branch 'test'
> mtn: committed revision a5705343748b44c784bbe1676d2dcdc42ad35a93
Just a side note here: I'm pretty sure I wouldn't want to have a bigger
team of developers doing work based on those ids. It's too easy in the
stress of normal daily work to just use an id that's not the one you
wanted... there's very little visual feedback here.
> monotone is warning us that we just created a new head on the branch by
> checking in that revision, based off of an older one.
CVSNT would tell you that you can't commit because you're working off an
older revision. At this point you have two choices (which probably is quite
similar to monotone, just the sequence is different): either you don't want
a separate branch, then you update (which merges), review, resolve any
conflicts and commit, or you want a separate branch, then you put your code
on a branch and commit without merging now. (That's not much different from
plain CVS and probably SVN.)
In monotone, AIUI, you commit, get notified at commit that you just created
a new head, and then decide whether to leave that head, thusly creating a
new branch, or merge the two heads. This is better in the sense of
maintaining history, as you have the code before the merge in the repo,
independently of whether you want to create a new branch or not. That's a
consequence of the ease of branching: it wouldn't be impossible to do in
CVSNT/CVS/SVN (you'd just always create a branch before you commit if you
have outdated revisions in files you want to commit), but since branching
is not as easy or even automatic, it's not being done, the merge is done in
the sandbox before the commit (if no branch is desired), and the code
before the merge is lost for posterity.
> Still, I haven't used CVSNT, it may very well have the same kind of
> feature set.
Not the same kind. The logic is different, and the sequence of commands is
different. But I think you can use it for the same style of development,
with a few differences.
For example one feature is quite handy for "cherry picking": bug ids. You
can associate arbitrary commits with a bug id. Later, you can use that bug
id to include (merge in) all changes related with that bug id on some other
branch. (I'm not sure, but I think the commits with the bug id don't even
have to be on the same branch. Usually they are, though... that's not the
system enforcing something, that's the logic of coding :) These bug ids
seem to be exactly what they talk about when talking about "cherry
picking".
You could probably also use those bug ids to easily maintain a set of
default setups like you were talking about. I think nobody has thought
about using it that way yet, but it's probably possible. I think one
requirement would be that all projects that use shared code like that need
to derive from the same branch, sub-branching it, so that the system can
identify the files correctly (which seems to be what you're doing, if I
understood that correctly). Definitely interesting, and definitely quite
different from common practice.
The other thing that CVSNT has that CVS doesn't (not sure about SVN) are
merge points. This is the relationship between two revisions of a file on
two different branches created through merging. The various visual tools
use that to show arrows between revisions whenever a merge happened.
However, it only tracks the end of the merge, not the start of it. Useful
for successive merges from one branch to another (say from a general
development branch to a feature branch, to keep the feature branch close to
the general dev branch), but not that useful if you use merging to "cherry
pick". That would need good bookkeeping (e.g. consistent use of the above
mentioned bug ids, and a carefully maintained list of which have been
picked already). Does monotone show you both start and end of such a
"cherry picking" merge?
Gerhard
Peter Todd
Hash: SHA1
On Thu, Aug 30, 2007 at 09:46:33AM -0300, Gerhard Fiedler wrote:
> On more reading, the ability to create a branch on commit (as opposed to
> creating it before editing) seems to be one thing that makes this easier to
> use for the "happy branching" style of development you're talking about.
> I'll have to try, but I think a script of some sort can do this with
> CVS/CVSNT/SVN repos also. This would definitely be helpful in some
> situations, especially when trying to use some of the techniques these docs
> describe.
>
> One thing I was wondering, and the docs I've read didn't touch this. Say
> you have revisions A, B, and so on through G implementing several features.
> Now you do some cherry picking and merge into a branch R the
> revisions/features D and E. The branch R advances with other changes, and
> at a later point you decide that you want more of these features. You
> forget that you already merged D and E, and just merge B through G into R.
> For all I know, on CVS/CVSNT/SVN, this would create merge conflicts on the
> places where D and E were merged in but modified (which often is needed
> when merging in), as the system has no way of knowing that the modification
> means the same thing as the original and is just necessary to integrate the
> original -- and they are also not smart enough to exclude the changesets D
> and E from the merge (because they already have been merged before).
>
> How's that in monotone? Does it remember that D and E have been merged in
> before and skips them when you tell it to merge B through G?
It depends on exactly how you were merging those changes in the first
place. If you were using the "daggy" style of adding features D and E
could have been implemented as children of the underlying A revision,
assuming they weren't dependent on B, C etc. In that case later merging
in B, C, D etc. is guaranteed to work as monotone has full history. This
is true even if you made significant changes to D and E after merging.
Merging child revisions of D and E into the branch will work as well,
with more or less effort (generally no effort in my experience)
depending on how extensive the changes are.
Now say on the other hand you use the pluck command. Pluck essentially
runs diff to find out what are the changes between two arbitrary
revisions. Then, using those changes, it runs patch to integrate those
changes into your workspace. In reality it's using monotones internal,
and smarter, diff and patch, but the principle is the same. From the
point of view of the revision control it's as though you manually typed
in the changes yourself, no history is tracked.
This means that when you later merge monotone is seeing the same change
get implemented independently on both heads of the merge. Fortunately
monotone handles that case just fine, and doesn't issue a conflict.
However if you needed to make changes you may see some conflicts on the
specific lines with changes, but this depends on the exact situation.
That said, once you've merged in the changes once, and gone though the
conflict resolution process, monotone generally can avoid conflicts on
later merges regardless of what you are doing.
Regardless it really helps to have a good merger program like xxdiff to
resolve conflicts. Instead of manually moving lines around you simply
select what lines on what files are correct and what order they should
be in. Monotone uses xxdiff by default if it's installed, and has
support for other similar programs.
Note that there is yet another revision control system, darcs, that (in
theory) handles this situation very well. It operates entierly on
patches and can automatically figure out what patches depend on what
based on the *text* of the patch. The whole idea of parent-child
relationships in revisions is eliminated.
The bad side is the algorithms behind it don't work yet, and may never
work. Currently they don't scale well so as your project gets bigger
darcs gets slower and slower until finally it comes to a grinding halt
trying to figure out patch dependencies. No-one knows if the math exists
to make this approach feasible.
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG3g033bMhDbI9xWQRAukcAJ0c81DVFfSwHlDxvo9P9XbVICaFHACfeBKh
YA/qDA9hzy4okpT3ugf+OOw=
=3nXA
-----END PGP SIGNATURE-----
Peter Todd
Hash: SHA1
On Thu, Aug 30, 2007 at 01:18:56PM -0300, Gerhard Fiedler wrote:
> > Mind you, remember that creating branches isn't the important part,
> > *merging* branches is. It's the merge that needs to be completely
> > painless.
>
> Whether merging is painless or not depends mostly on the code changes, and
> that's largely independent of any system. I'd say that managing the
> branches is the most important part -- which may have an influence on how
> easy merging goes. See my other post (just recently) with the question
> about an example where a "smart" exclusion of prior merged code could help
> a lot.
It's certainely true that managing branches is the key to how easy
merging is, but the whole point of a system like monotone is that you
are given the tools to manage branches properly in the first place.
Of course, nothing is going to help those poor souls who need to keep
revision controlled CAD drawings. The very nature of the work makes
merging changes a nightmare. Something like a PCB design just isn't
comparmentalized very well, regardless of what software you're using.
> > That also means that you don't get the enforced "merge before checkin"
> > problem that happens with a lot of revision control systems.
>
> If you work with branches, there's no "merge before checkin" problem.
> That's what I wrote about the creating of a branch on the fly on checkin in
> my other post. I think simplifying this is one of the major factors in
> making this simpler in monotone, but that's not something that's impossible
> with CVS/CVSNT/SVN. I'd have to try it, but I think a script can do that
> (creating a branch on the fly, with code that's already edited).
Yes, but then you end up with a pile of branch names for something that
doesn't deserve branch names. You could easilly end up needing to do
that dozens of times a day.
> > pete@inept:/tmp/test$ mtn ci
> > mtn: beginning commit on branch 'test'
> > mtn: committed revision a5705343748b44c784bbe1676d2dcdc42ad35a93
>
> Just a side note here: I'm pretty sure I wouldn't want to have a bigger
> team of developers doing work based on those ids. It's too easy in the
> stress of normal daily work to just use an id that's not the one you
> wanted... there's very little visual feedback here.
But see, that's actually the major *advantage* of hash based ids like
the above. Given a5705343748b44c784bbe1676d2dcdc42ad35a93 I am
absolutely guaranteed to get the correct data set back. Typo's are
rather unlikely to match something else. I'm also completely protected
from insidious data corruption.
Now if you want to it's quite easy to give id's tags. You can also use
branch names, especially easy in a one branch per feature setup.
Look at it this way, a CVS style 1.15.0.1 style revision id doesn't
really give you much feedback, but it does allow for typo's and it makes
it hard to be sure of what you're getting.
1b8e666561d4aeff479f47cab1ffdfe1057c82b8 has absolutely no feedback, but
figuring out what it means isn't tough, use mtn log and the like, and
prevents all sorts of nasty mistakes.
Also, as for typing length, if you type only the first few characters or
a revision id monotone will do it's best to complete the rest, or tell
you what revisions it could be.
> > monotone is warning us that we just created a new head on the branch by
> > checking in that revision, based off of an older one.
>
> CVSNT would tell you that you can't commit because you're working off an
> older revision. At this point you have two choices (which probably is quite
> similar to monotone, just the sequence is different): either you don't want
> a separate branch, then you update (which merges), review, resolve any
> conflicts and commit, or you want a separate branch, then you put your code
> on a branch and commit without merging now. (That's not much different from
> plain CVS and probably SVN.)
>
> In monotone, AIUI, you commit, get notified at commit that you just created
> a new head, and then decide whether to leave that head, thusly creating a
> new branch, or merge the two heads. This is better in the sense of
> maintaining history, as you have the code before the merge in the repo,
> independently of whether you want to create a new branch or not. That's a
> consequence of the ease of branching: it wouldn't be impossible to do in
> CVSNT/CVS/SVN (you'd just always create a branch before you commit if you
> have outdated revisions in files you want to commit), but since branching
> is not as easy or even automatic, it's not being done, the merge is done in
> the sandbox before the commit (if no branch is desired), and the code
> before the merge is lost for posterity.
But don't forget, you don't have to decide anything, it's completely
normal, and ok, for a branch to have more than one head. A branch is
just a special type of attribute attached to a revision, which can
belong to multiple branches. That's actually a very commmon situation,
for instance when "stable" branch has all the changes from the "devel"
branch merged into it. Branches are just names for humans to use,
underlying it all is that revisions are just a big set of nodes
connected to one another.
You're absolutely right though, monotone is just making things easier
that can be done otherwise. Of course, monotone is equally happy to
work without any branch names at all. :)
> > Still, I haven't used CVSNT, it may very well have the same kind of
> > feature set.
>
> Not the same kind. The logic is different, and the sequence of commands is
> different. But I think you can use it for the same style of development,
> with a few differences.
>
> For example one feature is quite handy for "cherry picking": bug ids. You
> can associate arbitrary commits with a bug id. Later, you can use that bug
> id to include (merge in) all changes related with that bug id on some other
> branch. (I'm not sure, but I think the commits with the bug id don't even
> have to be on the same branch. Usually they are, though... that's not the
> system enforcing something, that's the logic of coding :) These bug ids
> seem to be exactly what they talk about when talking about "cherry
> picking".
In monotone you could use one of two approaches there:
First, create a series of "branch.bug.BUGID" where for each bugid you
fix whatever was the problem as close to the source as possible. Then
you can merge that branch into stable, devel, whatever. You could even
make use of the testresult features, so part of writing the bugid branch
is to write a regression test and you can't merge the branch until the
test passes.
Secondly you could use one of the various ways to tag revisions, either
with a tag, or a specially formatted comment, or any number of methods.
Merging those changes into other branches would become a pluck
operation, with it's drawbacks, but still fairly workable I'd expect.
> You could probably also use those bug ids to easily maintain a set of
> default setups like you were talking about. I think nobody has thought
> about using it that way yet, but it's probably possible. I think one
> requirement would be that all projects that use shared code like that need
> to derive from the same branch, sub-branching it, so that the system can
> identify the files correctly (which seems to be what you're doing, if I
> understood that correctly). Definitely interesting, and definitely quite
> different from common practice.
Yup, sounds just like my system. The key would be how easy merges are
later on, but it could work.
> The other thing that CVSNT has that CVS doesn't (not sure about SVN) are
> merge points. This is the relationship between two revisions of a file on
> two different branches created through merging. The various visual tools
> use that to show arrows between revisions whenever a merge happened.
> However, it only tracks the end of the merge, not the start of it. Useful
> for successive merges from one branch to another (say from a general
> development branch to a feature branch, to keep the feature branch close to
> the general dev branch), but not that useful if you use merging to "cherry
> pick". That would need good bookkeeping (e.g. consistent use of the above
> mentioned bug ids, and a carefully maintained list of which have been
> picked already). Does monotone show you both start and end of such a
> "cherry picking" merge?
Yes and no. In the revision log monotone will clearly state what was the
start and end revisions of a cherry pick, however no-one has written a
visual tool that takes advantage of that yet. On the other hand if you
are making use of a "daggy-fixes" style approach, then the exact
features/bug fixes merged in will automatically show up in the visual
revision history.
As an example of the latter case I was recently producing a v1.1 of a
project. v1.0 was slightly different hardware, some pins changed, and I
decided to use a pic with 4k of flash rather than 2k. I had already
written the firmware for the v1.0 hardware and needed to fix some
issues.
I already had a v1.1 branch with the new hardware design, so the first
thing I did was I made the changes for my slightly different pic chip,
different makefile and some minor changes to the c files. Then I made
the IO pin changes. All in v1.1 branch.
Going back to the v1.0 branch I fixed some firmware issues and did an
explicit_merge of the correct revisions in 1.0 and the head of the 1.1
branch. All the changes were merged without a hitch.
I also made more changes to enable some features I'd wanted in v1.0, but
didn't have the flash memory space for.
All three steps were in practice interleaved, due to me finding more
bugs as the process went on.
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG3hjr3bMhDbI9xWQRAvqeAJ4l5ZElIOrlHaEEk+sh7jl0jdylKACfe40H
g86mnCiWn8o0YQd2i8I4740=
=YauU
-----END PGP SIGNATURE-----
Gerhard Fiedler
> It's certainely true that managing branches is the key to how easy
> merging is, but the whole point of a system like monotone is that you
> are given the tools to manage branches properly in the first place.
I think that's the conclusion here, for me. From what I can gather,
monotone has implemented a set of features that helps tremendously with
branch management.
> Yes and no. In the revision log monotone will clearly state what was the
> start and end revisions of a cherry pick, however no-one has written a
> visual tool that takes advantage of that yet.
In this sentence, you mention the probably most important issues (for me)
with monotone: good branch management, and lack of visual and integration
tools (at least on Windows, in the style of TortoiseCVS and SCC
integration).
> I already had a v1.1 branch with the new hardware design, so the first
> thing I did was I made the changes for my slightly different pic chip,
> different makefile and some minor changes to the c files. Then I made
> the IO pin changes. All in v1.1 branch.
>
> Going back to the v1.0 branch I fixed some firmware issues and did an
> explicit_merge of the correct revisions in 1.0 and the head of the 1.1
> branch. All the changes were merged without a hitch.
FWIW, this is quite similar to how I work.
This has been a very interesting exchange, and somehow we managed to avoid
the usual pissing contest ("my VCS is better than yours" :). I've learned a
bit, and I definitely will include monotone docs into my searches when I'm
looking for ideas about branch management in the future.
Gerhard
Peter Todd
Hash: SHA1
On Wed, Sep 05, 2007 at 08:17:26AM -0300, Gerhard Fiedler wrote:
> Peter Todd wrote:
>
> > It's certainely true that managing branches is the key to how easy
> > merging is, but the whole point of a system like monotone is that you
> > are given the tools to manage branches properly in the first place.
>
> I think that's the conclusion here, for me. From what I can gather,
> monotone has implemented a set of features that helps tremendously with
> branch management.
Pretty much, although I didn't mention a thing about how it allows for
distributed development, and the completely different security model...
But that's a whole discussion in itself... One that's probably fairly
irrelevant to single coders or small groups.
> > Yes and no. In the revision log monotone will clearly state what was the
> > start and end revisions of a cherry pick, however no-one has written a
> > visual tool that takes advantage of that yet.
>
> In this sentence, you mention the probably most important issues (for me)
> with monotone: good branch management, and lack of visual and integration
> tools (at least on Windows, in the style of TortoiseCVS and SCC
> integration).
Pretty much. Monotone is fairly young and the priorities of the people
working on it are less about Windows and more about enabling
decentralized development, especially for open source development
practices. Give it 5 years and maybe the trade-offs will be different.
> This has been a very interesting exchange, and somehow we managed to avoid
> the usual pissing contest ("my VCS is better than yours" :). I've learned a
> bit, and I definitely will include monotone docs into my searches when I'm
> looking for ideas about branch management in the future.
Oh sorry, I almost forgot, yeah, your VCS sucks... for me. :)
- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG4v4b3bMhDbI9xWQRAlPfAJ42bekdh0POEhui/KHYlzt91fiiDwCeKABF
hq+6eDnoHgZVtm6Z/aCVArA=
=LUMa
-----END PGP SIGNATURE-----