[U-Boot-Users] Revision control systems

[Wolfgang Denk]

Dear Jerry,

in message <4293A43A.7070306 at smiths-aerospace.com> you wrote:
> 
> Attached is a web page snapshot of my internal notes.  The problems that 

Thanks a lot. I really appreciate your help (and the style you  woirk
and document your work, too!).

> I'll continue playing with monotone and report what I find.  Merging 
> changes was a real pain for more than trivial changes.  It likely was my 
...
> Darc appears to be much easier to use than ARCH.  I know I had to do a 
> lot of recipe building with ARCH because I struggled to remember what 
> had to be done in what order.  All the darc review/feedback that I've 
> been reading talks about how much easier it is to use (granted, all the 
> pages were "how I switched from ARCH to darc" so they are biased :-)


After some more reading I feel it boils down to  a  decision  between
monotone and darc.


I would like to ask: who of you is actively using one or  the  other,
what  are  your experiences, which problems did you run into, etc. If
you have any "please use ... because ..." or "don't use  ...  because
..." statements I'd appreciate these, too.

But I'd rather not flood this list with such a  discussion  -  please
send  any such input to my direct address (wd at denx.de). I'll be happy
to post a summary.


> What I really like about ARCH and darc is the changeset cherry picking. 
>   It isn't clear that monotone would give me that capability as easily. 

If it's not available/good enough not today, it  will  come  soon,  I
think. The good thing of dropping BK for kernel development is that a
lot  of  new  power  now  goes  into the development of free software
alternatives.

>   I don't have enough experience to say for sure, however.  What I want 
> to do is:
> 1) Stay in sync with the u-boot master repository

Additionally, I want to get rid of a central  repository  because  it
does not match the way work gets done these days.

> 2) Source control our local customizations
> 3) Easily submit changesets to the master repository
> 4) If a changeset is rejected, keep the changes locally without having
>       to forever screw around with editing it out of new changesets
>       that I want to submit (i.e. easily and cleanly support delta
>       changesets).
> 5) If a changeset is accepted, be able to merge the official version
>       into my local tree without a lot of merging pain.  With darc and
...

Agreed completely.

> Disclaimer: If I were smarter, all of the above is probably do-able with 
> any source control system (even PVCS Dimensions ;-).

Ummm.. I guess you meant "If I were smarter and had more time, ..." -
yes, I know exactly what you mean ;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As in certain cults it is possible to kill a process if you know  its
true name.                      -- Ken Thompson and Dennis M. Ritchie