Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Catching up on mail after a couple of weeks with the flue. On Mon, 24 Jan 2011 00:13:46 -0800 Garrett Cooper yaneg...@gmail.com wrote: - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. Since no one else mentioned it - mercurial handles this with subrepos. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On 01/26/2011 12:00, Julian H. Stacey wrote: Hi, Alex order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). Some good points, but also remember make release also uses cvs grep CVS /usr/src/release/Makefile A) The fact that 'make release' uses cvs is not a feature B) It is quite trivially worked around (I speak from experience) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Hi, Alex order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). Some good points, but also remember make release also uses cvs grep CVS /usr/src/release/Makefile Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Wed, Jan 26, 2011 at 12:00 PM, Julian H. Stacey j...@berklix.com wrote: Hi, Alex order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). Some good points, but also remember make release also uses cvs grep CVS /usr/src/release/Makefile For convenience reasons, just like cdrtools exists purely for utility in release as well. As long as the license doesn't say [if you use our tool,] ur srcs are ours, then I don't see why license matters here. As and long as we package the source with the OS and all of our changes, or provide the ability to install it via a port, we should be ok. clang, llvm, compiler_rt, etc are a different can of worms as the GPLv2 // LGPLv2 is viral and says [if you use our tool with your srcs,] ur srcs have to be open (paraphrased of course), which doesn't work for companies who have proprietary IP. Thanks, -Garrett PS IANAL. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. BTW this topic came up on ports@ about 3 months ago: http://lists.freebsd.org/pipermail/freebsd-ports/2010-September/063675.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On 25 January 2011 11:22, per...@pluto.rain.com wrote: Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. Of course. OTOH, this topic will only become relevant if anyone notices that Subversion gets committed into base ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. This argument is actually a bit weak for most of the VCS'es out there (including svn by the way). We don't really *need* to import the full VCS itself into FreeBSD. For instance, Subversion is also not part of the base system. It works fine as a port that people can install. There's really _nothing_ wrong with a VCS that is a port/package. We used to have CVS into the base system as the official VCS, but this is no longer the case for the subversion repo of src/. IMO this hasn't really caused any major problem with the people who want to check out and patch the source tree. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Tue Jan 25 11, Giorgos Keramidas wrote: On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. This argument is actually a bit weak for most of the VCS'es out there (including svn by the way). We don't really *need* to import the full VCS itself into FreeBSD. For instance, Subversion is also not part of the base system. It works fine as a port that people can install. There's really _nothing_ wrong with a VCS that is a port/package. We used to have CVS into the base system as the official VCS, but this is no longer the case for the subversion repo of src/. IMO this hasn't really caused any major problem with the people who want to check out and patch the source tree. imo having a VCS in base is a bad idea. it makes it much harder to keep it in sync with the vendor version. to update a port involves very little administrative work. on the other hand updating vendor software in base involves quite a lot of importing etc. also please don't forget that having a VCS in base means there's only *one* version of the VCS available. having it in the ports tree makes it possible to have a legacy release, a stable release, an experimental release and also a development snapshot. of course there could be a stable release in base and if users want to they can install a more recent version from ports, but that doesn't really make sense imo. also a VCS is not really an essential part of an OS. with clang/llvm e.g. a version must exist in base, since it's not possible to invoke /usr/local in order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). so -1 for moving a new VCS to base. also i think freebsd should stick to a major VCS, like git and not some lesser known obscure VCS. with git you have all the linux people behind it, which means it will be updated regularly, bugs will be fixed quite fast etc. there's no point in switching to some rather unknown VCS where the developers decide after 2 years that they don't have any more spare time and have to abandon the project. to be quite honest: the freebsd community doesn't have the manpower to maintain a VCS by itself. you *need* other developers in order to keep it up to date. just look at GNATS e.g. gnu abandoned it quite a while ago and the bugbusting community is just to small to either update to a more recent version of GNATS or switch to something like bugzilla. again: you *need* support from other developers in order to maintain a VCS properly. so git is the best choice imo. just my 0.02$ cheers. alex -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Tue, Jan 25, 2011 at 01:40:50PM +0100, Giorgos Keramidas wrote: On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. This argument is actually a bit weak for most of the VCS'es out there (including svn by the way). Notice I never ever suggested we might want to do such a thing. All I said was there would be not a chance of GPL code being added. The additional argument of mercurial not being added because of its dependancy on python is immaterial. We don't really *need* to import the full VCS itself into FreeBSD. For instance, Subversion is also not part of the base system. It works fine as a port that people can install. I agree. Indeed, I would argue that there is other code in base that should come out. But I don't want to get that flamefest going again. ;-) The argument is not putting a VCS into base, the argument is what VCS to look at in future. 'fossil' is certainly a viable candidate. I am agreeing the arguments on which VCS to use should be based on the merits of the VCS itself, not on its licence. However, if in the long term we chose 'fossil' and then decided that 'fossil' was absolutely necessary for base, then it would have far less resistance than a GPL VCS. That's a small plus, I never said it was a strong plus. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Tue, Jan 25, 2011 at 02:05:17PM +, Alexander Best wrote: On Tue Jan 25 11, Giorgos Keramidas wrote: On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. ... no longer the case for the subversion repo of src/. IMO this hasn't really caused any major problem with the people who want to check out and patch the source tree. Note I never said it should be importable into base. also i think freebsd should stick to a major VCS, like git and not some lesser Argumentum ad populum. If the VCS is 1) easy to use 2) easy to maintain and has a body of people working on it already 3) can import other VCS formats, then why not? Also note that using an appeal to popularity suggests we should go with the flow and stop working on llvm/clang. Afer all, everyone else uses gcc. As it happens, fossil is quite tiny, fairly feature rich, BSDL'd and in active development. QED All that being said, I am not interested in bikeshedding right now. Those who will look at the alternatives intelligently should do so. cheers. alex - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On (24/01/2011 11:33), Alexander Best wrote: On Mon Jan 24 11, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. it would also be nice to have github running on freebsd.org. that way it would be much easier to discuss src changes without having to point people at a file, a function or even a specific line. also it would finally kill the mailinglists, which have lots of issues: spam, broken mailman installation, people going berserker when they see lines 80 etc. there have been a few attempts to introduce a code review system, but since that was all hosted on foreign websites the idea never cought on and afaik those websites weren't being supported/promoted by freebsd.org. Having github would be nice, but it's not open source. Another option could be gitorious, there are merge requests with review option[1], patch review, already hosted freebsd repository[2]. All we need as a first step is developers starting accepting merge requests from each other, people use it already[3]. 1. http://blog.gitorious.org/2009/11/06/awesome-code-review/ 2. http://gitorious.org/freebsd 3. http://gitorious.org/freebsd/repositories but personally i don't expect a change like this to happen in the near future. basically most of the freebsd administrative people are quite conservative. i wouldn't be surprised if some them are still trying to run freebsd on their typewriters. ;) cheers. alex Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn - cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). - More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Tue, Jan 25, 2011 at 11:09 PM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (24/01/2011 11:33), Alexander Best wrote: On Mon Jan 24 11, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. it would also be nice to have github running on freebsd.org. that way it would be much easier to discuss src changes without having to point people at a file, a function or even a specific line. also it would finally kill the mailinglists, which have lots of issues: spam, broken mailman installation, people going berserker when they see lines 80 etc. there have been a few attempts to introduce a code review system, but since that was all hosted on foreign websites the idea never cought on and afaik those websites weren't being supported/promoted by freebsd.org. Having github would be nice, but it's not open source. Another option could be gitorious, there are merge requests with review option[1], patch review, already hosted freebsd repository[2]. All we need as a first step is developers starting accepting merge requests from each other, people use it already[3]. 1. http://blog.gitorious.org/2009/11/06/awesome-code-review/ 2. http://gitorious.org/freebsd 3. http://gitorious.org/freebsd/repositories This is only for src though. I was going to start up some mirroring of ports as well on gitorious, but it would have been nice if it could have been covered like so: freebsd/docs.git freebsd/ports.git freebsd/src.git So that way people could just clone one of the above and work merrily in the component as they felt fit, or check out all three and work away as necessary. Plus it would be more 1:1 than it currently is. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn - cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). - More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon Jan 24 11, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. it would also be nice to have github running on freebsd.org. that way it would be much easier to discuss src changes without having to point people at a file, a function or even a specific line. also it would finally kill the mailinglists, which have lots of issues: spam, broken mailman installation, people going berserker when they see lines 80 etc. there have been a few attempts to introduce a code review system, but since that was all hosted on foreign websites the idea never cought on and afaik those websites weren't being supported/promoted by freebsd.org. but personally i don't expect a change like this to happen in the near future. basically most of the freebsd administrative people are quite conservative. i wouldn't be surprised if some them are still trying to run freebsd on their typewriters. ;) cheers. alex Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn - cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). - More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On 24.1.2011 9:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I think des is working on svnup to work directly on the SVN tree. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? As long as we're choosing bikeshed colour, I would like to drop mercurial here :) Mainly because of this: - Higher learning curve. I found Mercurial to have an easier learning curve and to be something like a DSCM for the users of CVS/SVN. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). I don't know if we're talking about the same thing, but I've also noticed git tends to do things the long way around which should be simple. Git's also much lower level. They both support pretty much the same feature set; here's a cute but dated comparison: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ Hg is/was AFAIK used by Sun. Anyway, personally, svn is good enough :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 5:33 AM, Ivan Voras ivo...@freebsd.org wrote: On 24.1.2011 9:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I think des is working on svnup to work directly on the SVN tree. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? As long as we're choosing bikeshed colour, I would like to drop mercurial here :) Mainly because of this: - Higher learning curve. I found Mercurial to have an easier learning curve and to be something like a DSCM for the users of CVS/SVN. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). I don't know if we're talking about the same thing, but I've also noticed git tends to do things the long way around which should be simple. Git's also much lower level. They both support pretty much the same feature set; here's a cute but dated comparison: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ Hg is/was AFAIK used by Sun. Anyway, personally, svn is good enough :) Ok. Obviously this was just a fleeting thought so let's close the git topic. I do hope that whatever des has cooking up though can replace cvsup/csup reliably though, and if CVS would die at least that would be nice... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 02:33:25PM +0100, Ivan Voras wrote: On 24.1.2011 9:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of ... As long as we're choosing bikeshed colour, I would like to drop mercurial here :) As long as it is not GPL. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: As long as it is not GPL. Unless there's a missing smiley in that sentence there, it is a tough requirement. Of the major SCMs, only Subversion is non-GPL-ed (even CVS is...). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote: On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: As long as it is not GPL. Unless there's a missing smiley in that sentence there, it is a tough IRL I'm known to be very dry humoured, I am deadly in e-mail or IRC. requirement. Of the major SCMs, only Subversion is non-GPL-ed (even QED CVS is...). CVS is/was dual licenced. There is also the work openbsd started with CVS sometime ago. Given the work that is being done on clang/llvm to get a non GPL compiler into the tree, perhaps efforts would be better spent on finding SCMs that were also non GPL. There certainly would not be a chance of putting mercurial or git into base for example. Perhaps a point to consider. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 11:48 AM, Diane Bruce d...@db.net wrote: On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote: On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: As long as it is not GPL. Unless there's a missing smiley in that sentence there, it is a tough IRL I'm known to be very dry humoured, I am deadly in e-mail or IRC. requirement. Of the major SCMs, only Subversion is non-GPL-ed (even QED CVS is...). CVS is/was dual licenced. There is also the work openbsd started with CVS sometime ago. Given the work that is being done on clang/llvm to get a non GPL compiler into the tree, perhaps efforts would be better spent on finding SCMs that were also non GPL. There certainly would not be a chance of putting mercurial or git into base for example. But we don't compile CVS, SVN, etc into our sources. I thought that was the whole point of doing the gcc - clang (and friends) conversion, not that the GPL is an undesirable license. Maybe I was missing something about the whole textproc stuff being replaced though (groff, etc) with NetBSD equivalents *shrugs*. Given that this is getting more philosophical than technical, maybe we should move the discussion elsewhere (i.e. not hackers@)? Perhaps a point to consider. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Mon, Jan 24, 2011 at 12:12:19PM -0800, Garrett Cooper wrote: On Mon, Jan 24, 2011 at 11:48 AM, Diane Bruce d...@db.net wrote: On Mon, Jan 24, 2011 at 08:02:37PM +0100, Ivan Voras wrote: On 24 January 2011 19:31, Diane Bruce d...@db.net wrote: ... But we don't compile CVS, SVN, etc into our sources. I thought which rcs. If you check, the file format on the SVN server is rcs compatible, in fact local checkins using svn will work just fine. Given that this is getting more philosophical than technical, maybe we should move the discussion elsewhere (i.e. not hackers@)? I'd suggest we support fossil (devel/fossil) http://fossil-scm.org No. But in future, keep in mind us old timers are not _that_ conservative. Perhaps a point to consider. Thanks! You are welcome. -Garrett - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
They both support pretty much the same feature set; here's a cute but dated comparison: http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ http://wiki.freebsd.org/VersionControl Table of features comparing SVN HG GIT MTN http://wiki.freebsd.org/ section Development resources (near base of page) Clickable to docs on Mercurial HG Git etc. Anyone having info not documented there already, could help by contributing there ? Maybe add another tool column or add another attribute row, whatever ? Disclaimer: I'm not an author, just a reader, no opinion on one over the other, but that table seems a central place to work toward informed choice ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Regardless of the benefits, unless there's someone to setup the infrastructure to run things, we're not going to change. We should at least have a master seed for git that people can pull from before we talk about doing anything further. git has the ability to pull from svn, so this should be relatively easy to get going. Warner On 01/24/2011 01:13, Garrett Cooper wrote: On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremypeterjer...@acm.org wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsensi...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, in which case syncing directly off the SVN master would seem a better approach. I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I wonder if it's time to look at another solution to this problem as these annoying stability issues don't appear to be going away. What about git? Just some things I'm able to rattle off that come to mind with git.. Some arguments `for git'... 1. One tool to rule them all: - cvsup/csup can be replaced with git archive [1]. - cvs git scales a bit better. - less support cost for p4 and lower likelihood of downtime in the event of critical failure (perforce's proprietary DB is a pain to recover I've recently discovered from other dealings). - svn- cvs exporter is no longer required as it's all one SCM. - As a side-effect, the bits present in CVS and SVN would now be 100% in sync, unlike cvs which can lead svn in terms of commits (at least that was the case when I last talked to someone about version numbering in pkg_install done by re@). 2. More evolved tool: - branches are cheap and can be local or remote. - distributed SCM seem to work well with large groups of developers. - works better with branching and merging from what I've seen. Some arguments against git... - The one caveat to cvsup/csup that's awesome is its componentization capability, i.e. being able to selectively download components in src / ports; I'm not 100% sure but there doesn't appear to be a clear analog in git. It might be achievable through gits remote.group in git-config, git-remote, etc, but I would need to prototype whether or not this is true. - Higher learning curve. - Some slightly annoying nits with stashing local changes when working on separate branches (need to talk to git maintainers). -More items might be here Some more git experienced folks could comment here, but it would be nice to unify all of the systems under `one flag' for the sake of simplicity and hopefully the sanity of the tool maintainers (Simon, et all). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
