[U-Boot-Users] Revision control systems

[U-Boot-Users] Revision control systems

[Jerry Van Baren]

Hi Wolfgang,

Are you still considering switching from CVS to a distributed version 
control system?  The following is a pretty interesting summary of a few 
of them:
<http://www.livejournal.com/users/bramcohen/17319.html?thread=163751>

I've dabbled with ARCH (tla) and monotone (only since the weekend) to 
pull the u-boot CVS into a local repository and merge/control local 
changes while tracking the master repository.  After reading the above 
article, I've been reading up on DARC as well.

With ARCH, my approach was to create a Sourceforge CVS -> ARCH master, 
using ARCH to create changesets that tracked the Sourceforge CVS master 
repository.  I then created a "local master" ARCH repository and applied 
the "master master" patchsets to the "local master".  I've had some 
problems tracking the master repository successfully.

Monotone looks promising because Linus was considering using it and 
because, according to the article, git closely resembles it.  If you're 
going to grab a tiger tail, might as well grab the tail of the biggest 
one ;-)  Monotone is designed to make multiple branches and multiple 
heads easy to create and merge, which seems to be a good way to go for 
tracking a master and simultaneously controlling local changes.  I don't 
have enough time in on it to see how well it works in practice.

DARC looks very promising for slaving off a master repository with local 
changes.  I like the idea of being able to easily forward a changeset to 
the Repository Master (you), and then, when it gets accepted, undo the 
local changeset and apply the master changeset.  ARCH can be used this 
way but DARC appears to be structured more for this type of usage with 
its emphasis on independent commutable patches.  How well it works in 
practice remains to be seen...

Thanks,
gvb

[U-Boot-Users] Revision control systems

[Wolfgang Denk]

Dear Jerry,

in message <4293794C.5020206@smiths-aerospace.com> you wrote:
> 
> Are you still considering switching from CVS to a distributed version 
> control system?  The following is a pretty interesting summary of a few 
> of them:
> <http://www.livejournal.com/users/bramcohen/17319.html?thread=163751>

Yes, I am - thanks a lot for the pointer!

The fact that we're not further down  that  road  is  caused  by  two
issues:  lots  of  lack  of  time  on my side, and the changes of the
toolchain used for the Linux kernel.

At the moment I feel a tendency to follow the LInux  kernel  and  use
the  same  tool  chain,  too  -  as  I  don't have any clear personal
preferences yet (and not enough time to play around and develop such)
I think it is more important to chose ONE toolchain instead of  which
one.  However,  I still hope that when the dust settles there will be
some other solution but git. It's not really clear to me if Linux has
settled with git forever, or if it's only a  stepping  stone  on  the
way.

Comments and input welcome!

> With ARCH, my approach was to create a Sourceforge CVS -> ARCH master, 
> using ARCH to create changesets that tracked the Sourceforge CVS master 
> repository.  I then created a "local master" ARCH repository and applied 
> the "master master" patchsets to the "local master".  I've had some 
> problems tracking the master repository successfully.

Do you have something like a step-by-step description one could esily
follow, and especially a little more details about the  problems  you
mentioned?

> Monotone looks promising because Linus was considering using it and 
> because, according to the article, git closely resembles it.  If you're 
> going to grab a tiger tail, might as well grab the tail of the biggest 
> one ;-)  Monotone is designed to make multiple branches and multiple 
> heads easy to create and merge, which seems to be a good way to go for 
> tracking a master and simultaneously controlling local changes.  I don't 
> have enough time in on it to see how well it works in practice.

:-( I am _especially_ interested in practical usage information about
Monotone.

> DARC looks very promising for slaving off a master repository with local 
> changes.  I like the idea of being able to easily forward a changeset to 
> the Repository Master (you), and then, when it gets accepted, undo the 
> local changeset and apply the master changeset.  ARCH can be used this 
> way but DARC appears to be structured more for this type of usage with 
> its emphasis on independent commutable patches.  How well it works in 
> practice remains to be seen...

I have to admit that I didn't know much about darcs before. I'm under
the impression that monotone is still a  more  likely  candidate  for
being the Linux kernel tool of choice, or am I wrong?

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
There are three ways to get something  done:  do  it  yourself,  hire
someone, or forbid your kids to do it.

[U-Boot-Users] Revision control systems

[Jerry Van Baren]

Wolfgang Denk wrote:
 > Dear Jerry,

[snip]

>>With ARCH, my approach was to create a Sourceforge CVS -> ARCH master, 
>>using ARCH to create changesets that tracked the Sourceforge CVS master 
>>repository.  I then created a "local master" ARCH repository and applied 
>>the "master master" patchsets to the "local master".  I've had some 
>>problems tracking the master repository successfully.
> 
> Do you have something like a step-by-step description one could esily
> follow, and especially a little more details about the  problems  you
> mentioned?

Attached is a web page snapshot of my internal notes.  The problems that 
I have are most likely due to my manual synchronizing and messing up, 
not due to ARCH itself.

>>Monotone looks promising because Linus was considering using it and 
>>because, according to the article, git closely resembles it.  If you're 
>>going to grab a tiger tail, might as well grab the tail of the biggest 
>>one ;-)  Monotone is designed to make multiple branches and multiple 
>>heads easy to create and merge, which seems to be a good way to go for 
>>tracking a master and simultaneously controlling local changes.  I don't 
>>have enough time in on it to see how well it works in practice.
> 
> :-( I am _especially_ interested in practical usage information about
> Monotone.

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 
fault: it uses gvimdiff, which I had not used before.  My problem was 
that it was an interactive operation that either worked completely or it 
started over from the begining, no stopping half way and restarting. 
Grrrrrrrrrrrr.  I had a quite a few files to merge so it took me way too 
many tries before completing (presumably) successfully.

>>DARC looks very promising for slaving off a master repository with local 
>>changes.  I like the idea of being able to easily forward a changeset to 
>>the Repository Master (you), and then, when it gets accepted, undo the 
>>local changeset and apply the master changeset.  ARCH can be used this 
>>way but DARC appears to be structured more for this type of usage with 
>>its emphasis on independent commutable patches.  How well it works in 
>>practice remains to be seen...
> 
> 
> I have to admit that I didn't know much about darcs before. I'm under
> the impression that monotone is still a  more  likely  candidate  for
> being the Linux kernel tool of choice, or am I wrong?

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 :-)

> Best regards,
> 
> Wolfgang Denk

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. 
  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
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
      ARCH (don't know about monotone) it appears that if I do changeset
      patches "right", I will be able to back out an accepted local
      changeset and then apply the official changeset.  Dependancies on
      other local changes can complicate this, obviously.

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

Thanks,
gvb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20050524/8ce8b362/attachment.html 

[U-Boot-Users] Revision control systems

[Wolfgang Denk]

Dear Jerry,

in message <4293A43A.7070306@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

[U-Boot-Users] Revision control systems

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jerry,

[snip]

> 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.

[snip]

> Best regards,
> 
> Wolfgang Denk

Just as an addendum to this discussion that is of general interest, on 
the darcs web site I found "Taylor"
   <http://darcs.net/DarcsWiki/Tailor>
which synchronizes different types of repositories (e.g. CVS -> 
monotone, CVS -> darcs).  It will even push changes back to CVS if you 
are adventurous.

I haven't tried it yet, but it looks incredibly useful.

gvb

[U-Boot-Users] Revision control systems

[Cliff Brake]

On 5/26/05, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
 
> Just as an addendum to this discussion that is of general interest, on
> the darcs web site I found "Taylor"
>    <http://darcs.net/DarcsWiki/Tailor>
> which synchronizes different types of repositories (e.g. CVS ->
> monotone, CVS -> darcs).  It will even push changes back to CVS if you
> are adventurous.

There is a similiar tool available for ARCH called tla-cvs-sync:
http://wiki.gnuarch.org/tla_2dtools

I used it awhile ago to sync my local u-boot ARCH repository to the
main CVS repository -- worked very well.

Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com