From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 24 May 2005 18:01:30 -0400 Subject: [U-Boot-Users] Revision control systems In-Reply-To: <20050524210621.AE933C1512@atlas.denx.de> References: <20050524210621.AE933C1512@atlas.denx.de> Message-ID: <4293A43A.7070306@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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