Re: [OT] Q: what would you choose for a VCS today
On Sat, Feb 02, 2008 at 11:49:10PM +0800, OutBackDingo wrote: I dont think I follow why people think its that hard to convert the FreeBSD src tree to some other RCS with history, branches and tags I seem to think this is doable. Seeing as Ive done it. And how did you convert it exactly? -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpou1f3Nettf.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
OutBackDingo wrote: I dont think I follow why people think its that hard to convert the FreeBSD src tree to some other RCS with history, branches and tags I have a FULL CVS conversion to a mercurial tree converted from a February 1, 2008 CVS snapshot. I also have a Full CVS converted to Subversion. And they have been to the best of my determinations thru ongoing testing fully converted. Id be more then happy to have others double check the integrity of both trees and see if something got missed. I seem to think this is doable. Seeing as Ive done it. And honestly Mercurial just rocks. Id prefer to host it externally if someone had some space, over all both trees consume space but not that incredibly awful. Any takers for testing? ok, so how do you pull revision 1.x.1.1 of ng_base.c from mercurial? (no, really I would like to know). One problem is tha tyour revision x of a file bears no relationship to my version x or the file. which makes comments like that bug was fixed in revision x of that file. Make sure you have at least that revision really hard to do. And you need to make a complete clone of the repo to play with a different branch of one file. You can't check out subtrees. On Sat, 2008-02-02 at 00:34 +0200, Adrian Penisoara wrote: Hi, On Jan 31, 2008 6:02 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2008 08:45:55 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Pretty much any post-CVS VCS will do that. But if you want a good merge facility, Perforce's are - well, after getting used to them, everything else feels like throwing your code against the wall and hoping the right parts stick. I talked to one of the git developers about a year ago, and they were thinking about adding a guided merge inspired by what Perforce does. I do trust you on Perforce being a strong contender for the job, but, unfortunately, looking at their licensing terms for OSS projects I do get some second thoughts. Perhaps that's why FreeBSD did not migrate mainstream sources over to P4 yet ;)... Thanks, Adrian Penisoara ROFUG / EnterpriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On Thu, Jan 31, 2008 at 11:00:25AM +0100, Johan Bucht wrote: I've only tried CVS, Mericurial, Clearcase and a bit of Subversion. And if you don't need IDE integration Mercurial seems to be working pretty good. I just read an article about the new merging and branching support coming in Subversion 1.5 and it looks like it might have some future. The IDE support is probably the best of the modern open source VCS. http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html Yes, merge tracking will definitely make it much easier to maintain branches in Subversion, including vendor branches containing a FreeBSD source tree. You can achieve much of the same effect by using the svnmerge.py script that ships with Subversion 1.4, but with 1.5 the server and client have merge tracking built in, so it's not a python script wrapper anymore, but a well-integrated feature. 1.5 has finally been branched a few days ago actually, so if you want to try it out go ahead and check out the branch and report any issues you find: svn co http://svn.collab.net/repos/svn/branches/1.5.x svn-1.5 -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgp5oO6TiUytn.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
On Fri, Feb 01, 2008 at 02:00:47AM +0200, Giorgos Keramidas wrote: Most tools seem to insist on trying to import the whole history of a CVS repository before they let you start doing any work in the newly converted repository. All conversion tools I've tried failed converting the FreeBSD repository. Not really. You can keep 'importing' snapshots of the src tree from any arbitrary CVS branch, if you are willing to wait until CVS checks out the first copy of the snapshot. Yes, sure. As described I eventually got around to use a cvs working copy as a base for importing snapshots of FreeBSD code as well. What would be nicer though would be something that could be pointed at the RCS files in the CVS repo to do the same, i.e. skip the working copy step. That's what I was looking for, also because of pure technical interest. But it's clear that from a functional point of view a script achieves the same thing just fine, albeit it's slower and wastes a bit of disk space. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpjhtzsGtju0.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
On Sat, 2 Feb 2008 00:34:58 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: On Jan 31, 2008 6:02 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2008 08:45:55 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Pretty much any post-CVS VCS will do that. But if you want a good merge facility, Perforce's are - well, after getting used to them, everything else feels like throwing your code against the wall and hoping the right parts stick. I talked to one of the git developers about a year ago, and they were thinking about adding a guided merge inspired by what Perforce does. I do trust you on Perforce being a strong contender for the job, but, unfortunately, looking at their licensing terms for OSS projects I do get some second thoughts. Perhaps that's why FreeBSD did not migrate mainstream sources over to P4 yet ;)... I've found the folks at Perforce to be very amenable to reasonable approaches. One of the founders is a strong FreeBSD advocate (IIRC, he once said Linux is cool. FreeBSD is double-plus cool.), and I suspect they'd love to have the main FreeBSD repository on Perforce. If the only thing preventing that was their OSS license terms, I'd be surprised if they wouldn't at least consider relaxing them for FreeBSD. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
According to Mike Meyer: If the only thing preventing that was their OSS license terms, I'd be surprised if they wouldn't at least consider relaxing them for FreeBSD. Perforce has already been thought as a replacement (back in 2000 when p4 was introduced) but it will not be able to deal with ports and even on projects right now, we have issues with too many client views/changesets. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
Hi, On Jan 31, 2008 6:02 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2008 08:45:55 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Pretty much any post-CVS VCS will do that. But if you want a good merge facility, Perforce's are - well, after getting used to them, everything else feels like throwing your code against the wall and hoping the right parts stick. I talked to one of the git developers about a year ago, and they were thinking about adding a guided merge inspired by what Perforce does. I do trust you on Perforce being a strong contender for the job, but, unfortunately, looking at their licensing terms for OSS projects I do get some second thoughts. Perhaps that's why FreeBSD did not migrate mainstream sources over to P4 yet ;)... Thanks, Adrian Penisoara ROFUG / EnterpriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ollivier Robert wrote: According to Mike Meyer: If the only thing preventing that was their OSS license terms, I'd be surprised if they wouldn't at least consider relaxing them for FreeBSD. Perforce has already been thought as a replacement (back in 2000 when p4 was introduced) but it will not be able to deal with ports and even on projects right now, we have issues with too many client views/changesets. Ports 2.0 is using aegis (aegis.sf.net)... any possibility for wider use? Note: I am in the middle of making it FreeBSD friendly and beefing up the automated portions of distributed repos - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com Free software != Free beer Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo6SkQi2hk2LEXBARAqFtAJ9fJ6zTzIdX10ZssmxZ3UApdD9XdgCeOA0F UKmqt5DZY0AFVA0ST/3QcU8= =CcGt -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
According to Aryeh M. Friedman: Ports 2.0 is using aegis (aegis.sf.net)... any possibility for wider use? Note: I am in the middle of making it FreeBSD friendly and beefing up the automated portions of distributed repos The day it can handle the loads that we have between src and ports, maybe but I don't think it can reasonably manage 16 csets... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ollivier Robert wrote: According to Aryeh M. Friedman: Ports 2.0 is using aegis (aegis.sf.net)... any possibility for wider use? Note: I am in the middle of making it FreeBSD friendly and beefing up the automated portions of distributed repos The day it can handle the loads that we have between src and ports, maybe but I don't think it can reasonably manage 16 csets... Last I heard it is up around the 15000 range on a Linux project. - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com Free software != Free beer Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo6X7Qi2hk2LEXBARArpOAJ9GKgKPCzqd2/kOnJ5Porb+RlAZcACfWr4h JMezLKHWTn4s+Myk1Kr86Nw= =WPA3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
I dont think I follow why people think its that hard to convert the FreeBSD src tree to some other RCS with history, branches and tags I have a FULL CVS conversion to a mercurial tree converted from a February 1, 2008 CVS snapshot. I also have a Full CVS converted to Subversion. And they have been to the best of my determinations thru ongoing testing fully converted. Id be more then happy to have others double check the integrity of both trees and see if something got missed. I seem to think this is doable. Seeing as Ive done it. And honestly Mercurial just rocks. Id prefer to host it externally if someone had some space, over all both trees consume space but not that incredibly awful. Any takers for testing? On Sat, 2008-02-02 at 00:34 +0200, Adrian Penisoara wrote: Hi, On Jan 31, 2008 6:02 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2008 08:45:55 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Pretty much any post-CVS VCS will do that. But if you want a good merge facility, Perforce's are - well, after getting used to them, everything else feels like throwing your code against the wall and hoping the right parts stick. I talked to one of the git developers about a year ago, and they were thinking about adding a guided merge inspired by what Perforce does. I do trust you on Perforce being a strong contender for the job, but, unfortunately, looking at their licensing terms for OSS projects I do get some second thoughts. Perhaps that's why FreeBSD did not migrate mainstream sources over to P4 yet ;)... Thanks, Adrian Penisoara ROFUG / EnterpriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Penisoara wrote: Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? I'm having to use mercurial. I'm not really enjoying it. works ok for small projects. BSD is a bit big for it. doe work foe offline editing, but loses all your BSD history. probably SVK is the way to go from what I hear. For the moment I am thinking that the top contenders would be Bazaar and Mercurial but I would like to know other (developer) opinions. Aegis aegis.sf.net and devel/aegis... to get it to compile you will need to apply a patch I will send you if you want (and/or use the yet to be committed devel/aegis-devel which does the patch at the cost of failing portlint [installs correctly and all that but has some minor issues that prevent committing as of yet]) currently I am working with the aegis developers so none of the hacks (plus a few other things) are not needed (i.e. no special cases needed for freebsd)... to others reading this is going to be the primary cms/vms/vcs for ports 2.0 - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com Free software != Free beer Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoXALQi2hk2LEXBARAnLUAKClqkEkOGaE6A5ZkNW/dYeIidpzAACaAkRS ZrJDj6I380VjISP65lVN8ek= =TGs6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
Am Donnerstag, 31. Januar 2008 10:03:22 schrieb Julian Elischer: I'm having to use mercurial. I'm not really enjoying it. works ok for small projects. BSD is a bit big for it. doe work foe offline editing, but loses all your BSD history. We're using mercurial pretty much for all of our (100,000+ SLOC) repositories, and I cannot agree that it's only appropriate for small projects. As mercurial is a distributed RCS, the hard part in using it is you have to impose some policies, esp. related to merging changes back into a central repository, which aren't required for centralized systems like CVS and subversion, but from my view, the added benefit for a developer in using a distributed revision control system is well worth the extra effort in writing (and thinking) up the policies once. mercurial (at least by default) doesn't allow you to create remote branches anyway (in pushing back changes to the central store), so the policies you might have are effectly enforced by the system anyway. YMMV, of course, and mercurial has its defects (primary checkout/cloning of a large repository from a central store takes ages, at least over a slow link, the last time I had to do this [but I don't know if any progress has been made there]), but for me, it's been working fine for the daily needs I have as a developer. -- Heiko Wundram Product Application Development ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
I've only tried CVS, Mericurial, Clearcase and a bit of Subversion. And if you don't need IDE integration Mercurial seems to be working pretty good. I just read an article about the new merging and branching support coming in Subversion 1.5 and it looks like it might have some future. The IDE support is probably the best of the modern open source VCS. http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html /Johan On Jan 31, 2008 10:25 AM, Heiko Wundram (Beenic) [EMAIL PROTECTED] wrote: Am Donnerstag, 31. Januar 2008 10:03:22 schrieb Julian Elischer: I'm having to use mercurial. I'm not really enjoying it. works ok for small projects. BSD is a bit big for it. doe work foe offline editing, but loses all your BSD history. We're using mercurial pretty much for all of our (100,000+ SLOC) repositories, and I cannot agree that it's only appropriate for small projects. As mercurial is a distributed RCS, the hard part in using it is you have to impose some policies, esp. related to merging changes back into a central repository, which aren't required for centralized systems like CVS and subversion, but from my view, the added benefit for a developer in using a distributed revision control system is well worth the extra effort in writing (and thinking) up the policies once. mercurial (at least by default) doesn't allow you to create remote branches anyway (in pushing back changes to the central store), so the policies you might have are effectly enforced by the system anyway. YMMV, of course, and mercurial has its defects (primary checkout/cloning of a large repository from a central store takes ages, at least over a slow link, the last time I had to do this [but I don't know if any progress has been made there]), but for me, it's been working fine for the daily needs I have as a developer. -- Heiko Wundram Product Application Development ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
I'm having to use mercurial. I'm not really enjoying it. works ok for small projects. BSD is a bit big for it. doe work foe offline editing, but loses all your BSD history. probably SVK is the way to go from what I hear. Im using mercurial on full FreeBSD trees, curiosity makes me ask where do you the deficiency? Ive had no issues patching, branching, merging, transplanting, tracking vendor updates. The only issue i really had was a import of the full cvs tree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
Adrian Penisoara [EMAIL PROTECTED] writes: Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Subversion, hands down. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On Thu, 31 Jan 2008 08:45:55 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Pretty much any post-CVS VCS will do that. But if you want a good merge facility, Perforce's are - well, after getting used to them, everything else feels like throwing your code against the wall and hoping the right parts stick. I talked to one of the git developers about a year ago, and they were thinking about adding a guided merge inspired by what Perforce does. For the moment I am thinking that the top contenders would be Bazaar and Mercurial but I would like to know other (developer) opinions. I last looked at distributed VCS systems about a year ago, and at the time liked Mercurial. The technology seems like it would be great for a project like FreeBSD. However, best practices for using them were still being worked out, and I'm not sure I'd want to commit a long-term project to one under those conditions. For a centralized VCS systems I've checked, perforce is the best of the post-CVS systems (and the only one that doesn't leave turds in the build tree). Subversion is a close second, but is still a little rough around the edges. Most notably, merge tracking is in the 1.5 beta builds, but not in the production code. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On Thu, 2008-01-31 at 11:02 -0500, Mike Meyer wrote: On Thu, 31 Jan 2008 08:45:55 +0200 Adrian Penisoara [EMAIL PROTECTED] wrote: Subversion is a close second, but is still a little rough around the edges. Most notably, merge tracking is in the 1.5 beta builds, but not in the production code. mike At $JOB, we moved to subversion from CVS about 2-3 years ago. We're still using subversion for everything, and use svnmerge.py [1] to manage development and release branches. It isn't ideal, as you lose information about the individual commits within a merged patchset, which makes it a minor pain to back out a specific commit from a merged patchset. Other features we're looking forward to is read-only slaves that post back commits to a global master site, which would greatly please our North American colleagues, save them from having to pull repos from over the pond. Tom [1] http://www.orcaware.com/svn/wiki/Svnmerge.py signature.asc Description: This is a digitally signed message part
Re: [OT] Q: what would you choose for a VCS today
OutBackDingo wrote: I'm having to use mercurial. I'm not really enjoying it. works ok for small projects. BSD is a bit big for it. doe work foe offline editing, but loses all your BSD history. probably SVK is the way to go from what I hear. Im using mercurial on full FreeBSD trees, curiosity makes me ask where do you the deficiency? Ive had no issues patching, branching, merging, transplanting, tracking vendor updates. The only issue i really had was a import of the full cvs tree so if I ask you to show me version 1.3 of ng_base.c and compare it to version 1.5, how do you do that? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
At 8:45 AM +0200 1/31/08, Adrian Penisoara wrote: Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? You'll probably get a different answer from each person... :-) As for me, I'd go with subversion. I also believe 'git' might be a very interesting choice, but I haven't used it enough to know how well it works in practice. And I think that's the basic difficulty in trying to answer your question. Very few people have enough experience with all of the available VCS systems to do a comparison. I have worked a lot with RCS and CVS. I've done a little with perforce, but it is so different than CVS that I can't say that I gave it a fair chance. I just thought Oh boy, this is too weird!, and went on to some other project. I don't have enough time to take a real project, and try to make the same set of changes to multiple copies of the repository, to see which VCS *really* does a better job for everything which is needed. One of the guys I know swears that darcs is the best thing ever, and I can see how it would work well for some projects, but I can't imagine it working well for a project such as FreeBSD. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On Thu, Jan 31, 2008 at 08:45:55AM +0200, Adrian Penisoara wrote: Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Finally a thread to vent about this topic :) I'd very much like to hear how others are doing this, please post, people, I'll read it all. Here's my take on it. I'm only talking about maintaining local changes, not what the FreeBSD project per se should use for change management, and also I don't really talk about working in a team but it's probably still relevant and might help: Don't _ever_ follow development(7) and try to maintain one or more custom branches inside a cvsup'd copy of the FreeBSD CVS repo. I've been down that road. It sucks. It really prevented me from getting any work done while waiting for hours on end for cvs to set a tag, do an update, a commit, let alone a merge. Every operation took ages and ages. With two branches, one based on RELENG_6 and CURRENT at the time, merging changes between the two was a major pain. CVS had so much overhead for me that using it made the whole point of doing version control fly out the window from, say, the 42nd floor. I've investigated quite a few options to maintain modifications to FreeBSD since, mainly to manage wake on lan patches (see http://stsp.name/wol/) but also local bug fixes I need for my system (e.g. enabling AIGLX does not lock up my 6.3 box so I can run compiz, see PR #114688). I'm quite serious about version control. In fact I'm a partial and (currently) paid committer for the subversion project, so I could even say that I'm involved in version control professionally. What I wanted instead of CVS sounds fairly simple to me: To maintain my local mods to FreeBSD I don't really care about the whole CVS history. I just need to be able to take a snapshot at some point, put it on a branch, and keep importing upstream changes incrementally to that branch from there on. So a vendor branch, but without any (or as little as possible) manual labour involved in updating it. I could not find any tool that does this properly among subversion, git, monotone and mercurial. That's not a big list, but I don't have time to try out version control systems all day. Also, proprietary VCS's were never considered (I also keep my freebsd kernels blob-free, call me a hippie or whatever if you want :P) Most tools seem to insist on trying to import the whole history of a CVS repository before they let you start doing any work in the newly converted repository. All conversion tools I've tried failed converting the FreeBSD repository. git-cvsimport fails after a few minutes because cvsps produces bad output when run on the FreeBSD repo. I reported this to the git developers and as a result they made git-cvsimport error out correctly, but did not fix the actual issue. The monotone built-in cvs converter segfaulted after running a whole day. The generic tailor VCS conversion tool failed as well -- I don't remember how, it errored out after running for a while. Even though I am subversion dev I did not try cvs2svn, because I wanted to take this as an opportunity to get my feet wet in another VCS. Mercurial failed to convert the repo, too, and there was no way of telling it not to try to import the whole history either. But its handbook describes interesting alternative approach to vendor branches: Patch queues. If you think you need a vendor branch, take a look at mercurial patch queues and consider if they might do the job just as well: Managing change with Mercurial Queues: http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 Advanced uses of Mercurial Queues: http://hgbook.red-bean.com/hgbookch13.html#x17-30200013 I won't explain the details in this mail, as duplicating information from the handbook is a waste of time, but I'll give you my opinion: Patch queues are quite powerful, and even though you end up versioning diffs instead of whole files, the patch queue provides a nice enough abstraction that makes maintaining local changes as comfortable as maintaining a vendor branch. A big plus is that you do not need to take an extra step to generate diffs to send upstream, because you already have the diffs right in your .hg/patches directory. Conflict resolution works almost the same way as during a normal VCS's merge (whatever normal means in version control land :P), and as you get to incrementally make the patches in your queue apply again, you don't have to deal with a source tree full of all conflicts of a merge, but only with conflicts caused by a single patch at a time. Patch guards let you apply patches conditionally, this is where it gets interesting if you maintain changes for, say, RELENG_7 and CURRENT at the same time, and still
Re: [OT] Q: what would you choose for a VCS today
On 2008-01-31 21:37, Stefan Sperling [EMAIL PROTECTED] wrote:
I could not find any tool that does this properly among subversion,
git, monotone and mercurial. That's not a big list, but I don't have
time to try out version control systems all day. Also, proprietary
VCS's were never considered (I also keep my freebsd kernels blob-free,
call me a hippie or whatever if you want :P)
Most tools seem to insist on trying to import the whole history of a
CVS repository before they let you start doing any work in the newly
converted repository. All conversion tools I've tried failed converting
the FreeBSD repository.
Not really. You can keep 'importing' snapshots of the src tree from any
arbitrary CVS branch, if you are willing to wait until CVS checks out
the first copy of the snapshot.
This is how we 'resync' with the official doc/ tree changes in the Greek
translation team:
(a) We keep a Mercurial workspace which is read-only to everyone
else, except the importer.
(b) The importer checks outs doc/ snapshots and commits them as
'vendor code drops' in http://hg.hellug.gr/freebsd/doc/
(c) I pull changes from the 'import tree' into my own personal
workspace, and merge them with the latest translation effort text.
(d) Then the merged tree is pushed to a second 'workspace', 'branch'
or whatever you prefer calling it, at http://hg.hellug.gr/freebsd/doc-el/
The whole process of importing clean snapshots is automated in a shell
script, which I manually kick off at this point:
% #!/bin/sh
%
% cd /ws/doc/bsd
%
% # 1. Start from a clean slate for the next import
% rm -fr *
%
% # 2. Check out a clean copy of a partial doc/ tree.
% cvs -d /home/ncvs co -d . -l doc
% cvs -d /home/ncvs -qR up -APd * share \
% en_US.ISO8859-1 el_GR.ISO8859-7
% find . -type d -name CVS -exec rm -r {} +
%
% # 3. Update mercurial's idea of the current workspace state,
% # hg adding new files, and hg removing gone stuff.
% hg addremove
%
% # 4. Find out the $FreeBSD$ timestamp of the latest patch we are
% # about to commit. Note that this may be a bit silly, because it
% # won't correctly detect -kb files being added after the last
% # $FreeBSD$ id change. A better way would use -D to checkout from
% # CVS, so that a timestamp would be automatically known.
% timestamp=$( hg diff | grep '^+.*FreeBSD:' | \
% sed -e 's/.*,v //' | awk '{print $1,$2}' )
%
% # Commit everything to Mercurial.
% hg ci -u ncvs -d ${timestamp} + \
% -m Import FreeBSD doc/ snapshot at ${timestamp} +
That's not something I would like doing manually several times a day,
but it certainly isn't impossible.
Naturally, similar scripting can be installed for Subversion, Git,
Bazaar, or darcs if that's your personal preference.
Mercurial failed to convert the repo, too, and there was no way of
telling it not to try to import the whole history either.
Snapshot-based import sof FreeBSD code as `vendor imports' are really
*VERY* easy to script in Subversion, Mercurial, Git and Bazaar. Been
there, done that several times, and I can help you if you plan to do
something like this with any of the aforementioned VCSes.
So far, this setup hasn't failed me, and the speed is several orders of
magnitude higher than using CVS branches.
That's my impression too :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On 2008-02-01 02:00, Giorgos Keramidas [EMAIL PROTECTED] wrote: You can keep 'importing' snapshots of the src tree from any arbitrary CVS branch, if you are willing to wait until CVS checks out the first copy of the snapshot. This is how we 'resync' with the official doc/ tree changes in the Greek translation team: (a) We keep a Mercurial workspace which is read-only to everyone else, except the importer. (b) The importer checks outs doc/ snapshots and commits them as 'vendor code drops' in http://hg.hellug.gr/freebsd/doc/ (c) I pull changes from the 'import tree' into my own personal workspace, and merge them with the latest translation effort text. (d) Then the merged tree is pushed to a second 'workspace', 'branch' or whatever you prefer calling it, at http://hg.hellug.gr/freebsd/doc-el/ The whole process of importing clean snapshots is automated in a shell script, which I manually kick off at this point: An much improved snapshot import script is now finished (for some odd definition of `improved' I guess), even thought it is still a bit ugly for my taste. http://people.freebsd.org/~keramida/scripts/bsd-doc-import.ksh.txt I'd probably prefer Perl for some of the stuff done in ksh(1) there, but no time for that tonight, and it seems to work as a 'proof of concept' of importing partial checkouts from CVS to Hg without having to go through all the hoops of converting the *full* history. The cron job entry which runs this is: # Try to import a snapshot of the BSD doc/ tree once an hour. @hourly $HOME/bsd-doc-import.sh $HOME/hg/doc/bsd-import This is getting pretty off-topic for freebsd-hackers though, so it's probably time for me to shuttup and go do something useful :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[OT] Q: what would you choose for a VCS today
Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? For the moment I am thinking that the top contenders would be Bazaar and Mercurial but I would like to know other (developer) opinions. Thank you for your time, no flames please. Adrian Penisoara ROFUG / EntepriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian Penisoara wrote: Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? For the moment I am thinking that the top contenders would be Bazaar and Mercurial but I would like to know other (developer) opinions. Aegis aegis.sf.net and devel/aegis... to get it to compile you will need to apply a patch I will send you if you want (and/or use the yet to be committed devel/aegis-devel which does the patch at the cost of failing portlint [installs correctly and all that but has some minor issues that prevent committing as of yet]) currently I am working with the aegis developers so none of the hacks (plus a few other things) are not needed (i.e. no special cases needed for freebsd)... to others reading this is going to be the primary cms/vms/vcs for ports 2.0 - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com Free software != Free beer Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoXALQi2hk2LEXBARAnLUAKClqkEkOGaE6A5ZkNW/dYeIidpzAACaAkRS ZrJDj6I380VjISP65lVN8ek= =TGs6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
