[Nitro] Darcs troubles

transfire at gmail.com transfire at gmail.com
Mon Feb 12 20:41:49 EST 2007



On Feb 12, 5:57 pm, "Jonathan Buch" <j... at oxyliquit.de> wrote:

> * probably some waterlilly in south japan which got stomped by
>    an egyptian camel

damn camels! :)

> There will be more such signes, the further the inconsistent state
> of the repo 'progresses' and soon after there will be, like, no
> clean patch anymore.
>
> Solution:
>
> * get clean repo from George
> * merge changes by hand (diff/patch, copy/paste)
> * make clean `darcs record`
> * send patch to G
> * repeat
>
> When only working alone on a repo, this cycle will not be needed all too
> often.  It's just that darcs gets confused, and if it does, bad things
> start to happen.
>
> I have 2 main repos:
>
> 1. clean George repo
> 2. my dev repo
>
> * often pull G repo [1.]
> * darcs pull ../nitro-0.40-george (only get 'good' patches) [2.]
> * darcs record [2.]
> * darcs send -o patchfile ../nitro-0.40-george [2.]
> * wait for G to apply, repeat
>
> When George 'reworks' a patch (meaning, he uses your patch internally, but
> makes changes to it and releases a new patch with it), you can almost throw
> away your repo and make a clean one.  You have to observe via source what
> you're pulling and how it affects code you touched.
>
> This sounds like stress?  Maybe.  Am I just ranting?  Possibly.
>
> But this doesn't mean that I don't like darcs.  I love it, it's imo the
> most 'comforting' system around...

I have to admit that the SCM doesn't work too well for me. I'm not
blaming Darcs per say --I had troubles with Subversion too when I
tried it. I'm just not SCM mined I guess. But I think the whole
distributed SCM may be over-hyped just a little. It would still be
nice if we were all pushing back to a central repo, rather then
passing patches to George. However --and a big however, Nitro/Og is
still maturing and going through many changes and that thwarts coop
development a great deal. That's okay, Nitro/Og needs it and I have a
feeling this round of major changes will be essentially the last (yea!
onward to 1.0!)

Even so, I have a suggestion for correcting the problem and one that I
am currently moving toward in my own projects. I think it's a very
good idea to divide the system into smaller components. Each component
having it's own darcs repo. That way it becomes easy to work on a
particular component without stepping on others toes. Also, it makes
one much more aware of when an interface changes vs.just changing
internal functionality, b/c it will have an effect on other components
or not.  Nitro's already consists of two divisions: nitro and og.
Splitting darcs along that division in itself would help but we can go
further. Nitro's template systems could be their own microprojects,
for instance. Even Og's adapters could each be there own microproject
--just depends on how far we think is best to take it. It's more like
thinking in terms of parts -- we develop individual parts that
eventually come together to create the whole. Its a good way to
develop, b/c it helps to get the SOCs right.

This requires some working out details on how best to achieve it
though. I've been thinking about that myself b/c i want to do it for
Facets/More lib. Right now I have every lib in a single dir.

  facets/
    ProjectInfo
    lib/
      facets/
        more/
          ann.rb
          ann_attr.rb
          cut.rb
           ...etc...

What I want to do is something like (maybe, maybe not keeping more/
dir):

  facets/
    ProjectInfo
    ann/
      lib/
        facets/
          ann.rb
          ann_attr.rb
    cut/
      lib/
        facets/
          cut.rb

That way, each more-part can have it's own versioning, plus docs, etc.
It would be much better this way for may reasons, not the least of
which is it would also make it easier to depend on a specific
component if that's all one needs. The difficulty though is how to
build the final full product. At this point I think the only way to do
it is to write a special script or rake task that builds a staging of
the final product --it's too bad, setup.rb supports this layout via
packages/ dir, but gems does not. Even so, I can build the tool to
handle this -- or perhaps there's a better way to achieve the same?

Thoughts?
T.



More information about the Nitro-general mailing list