Hi Aron,
On 3/30/06, Aron Griffis [EMAIL PROTECTED] wrote:
I think we might be best to try three revision control systems to
start: darcs, git and subversion. Three seems like a lot, but each
has its reason, and we can anticipate darcs being used primarily by
the haskell team rather than for
On Fri, Mar 31, 2006 at 09:16:17AM +0100, Stuart Herbert wrote:
Hi Aron,
On 3/30/06, Aron Griffis [EMAIL PROTECTED] wrote:
I think we might be best to try three revision control systems to
start: darcs, git and subversion. Three seems like a lot, but each
has its reason, and we can
On Fri, 2006-03-31 at 10:24 +0200, Fernando J. Pereda wrote:
On Fri, Mar 31, 2006 at 09:16:17AM +0100, Stuart Herbert wrote:
Hi Aron,
On 3/30/06, Aron Griffis [EMAIL PROTECTED] wrote:
I think we might be best to try three revision control systems to
start: darcs, git and subversion.
Is there a concensus out of this thread, on the topic of a distributed
VCS? :) Preferrably from devs who will actually want overlays? :)
Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list
On 3/28/06, Patrick McLean [EMAIL PROTECTED] wrote:
I think git is probably the best choice, I have played with it a little
myself and it is _very_ powerful, it also has a very simple dependency
set (all it's deps are in the Gentoo core system, and are either
available or installed by default
On Monday 27 March 2006 22:58, Dan Armak wrote:
This thread [1] from subversion-users asked about update/checkout
performance. The svn people answered that performance usually isn't
constrained by reassembly time. Moreover, the older BDB repo format stores
the complete latest revision, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando J. Pereda wrote:
On Sun, Mar 26, 2006 at 06:39:15AM +0200, Luca Barbato wrote:
git : c+bash (and optional perl/python for some merge scripts)
I think git is probably the best choice, I have played with it a little
myself and it is _very_
On Monday 27 March 2006 07:43, Ryan Phillips wrote:
Aron Griffis [EMAIL PROTECTED] said:
Have you followed the threads in the past regarding using other
version control systems for portage? Some devs have done benchmarks
and found that there are blocking issues with subversion,
On 27/03/06, Ryan Phillips [EMAIL PROTECTED] wrote:
Aron Griffis [EMAIL PROTECTED] said:
Have you followed the threads in the past regarding using other
version control systems for portage? Some devs have done benchmarks
and found that there are blocking issues with subversion,
On Mon, 2006-03-27 at 09:51 +0100, Chris Bainbridge wrote:
On 27/03/06, Ryan Phillips [EMAIL PROTECTED] wrote:
Aron Griffis [EMAIL PROTECTED] said:
Have you followed the threads in the past regarding using other
version control systems for portage? Some devs have done benchmarks
and
On Monday 27 March 2006 10:29, Paul de Vrieze wrote:
On Monday 27 March 2006 07:43, Ryan Phillips wrote:
In actuality, Subversion does 98% of the commit in an initial
transaction, and the blocking only occurs in the last 2% with the FSFS
filesystem. It really isn't an issue and shouldn't
On Sat, Mar 25, 2006 at 07:57:43PM -0500, Aron Griffis wrote:
Fernando J. Pereda wrote: [Sat Mar 25 2006, 06:18:52PM EST]
Well, I find it easier to understand than many other DVCSs out there...
In fact I don't think it is difficult to use in any way. Maybe pre-1.1
versions had some syntax
On Sun, Mar 26, 2006 at 06:39:15AM +0200, Luca Barbato wrote:
git : c+bash (and optional perl/python for some merge scripts)
Just for clarifying things:
A strict server doesn't need perl or python (not even bash) though bash
is highly recommended.
A client NEEDS python because the 'recursive'
On Sat, Mar 25, 2006 at 07:57:43PM -0500, Aron Griffis wrote:
Fernando J. Pereda wrote: [Sat Mar 25 2006, 06:18:52PM EST]
Well, I find it easier to understand than many other DVCSs out there...
In fact I don't think it is difficult to use in any way. Maybe pre-1.1
versions had some syntax
Aron Griffis [EMAIL PROTECTED] said:
Have you followed the threads in the past regarding using other
version control systems for portage? Some devs have done benchmarks
and found that there are blocking issues with subversion, particularly
because of its repo-wide revisions that prevent
Stuart Herbert wrote:
Thanks for the summary. I think that's a fair assessment of where we are at.
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed
On Sat, 25 Mar 2006 03:31:34 +0100
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
Although I don't know darcs at all in terms of use and feature, I
would really suggest to _not_ use it. For a simple reason, actually:
cvs has almost no cost added, as it's present on every major
On Sat, 2006-03-25 at 03:31 +0100, Diego 'Flameeyes' Pettenò wrote:
Darcs, instead, is written in Haskell, which means you need architectures
that
supports Haskell, and in which it's stable enough to work... considering we
have Gentoo/Alt, it's not that good to cut us off (yes I know I
On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
This is a valid issue, as ghc is only supplied upstream for linux (some
older versions available in mingw32).
I don't think this is right. All the recent ghc versions have been
supplied upstream on many OSs including installers
On Saturday 25 March 2006 12:42, Kevin F. Quinn (Gentoo) wrote:
If you're suggesting CVS as the second VCS (i.e. in addition to SVN)
then I don't see the point - SVN is simply a better CVS and clients
should be available on the alt platforms.
No, I was just stating the fact that cvs in itself
On Saturday 25 March 2006 12:41, Duncan Coutts wrote:
We've got ghc working on ppc-osx and ghc of course works on FreeBSD
(it's in FreeBSD ports) so all it needs is a helper for Gentoo/FreeBSD.
NetBSD, OpenBSD, GNU/kFreeBSD, GNU/Hurd, Solaris?
Really it's not a cheap dependency as it is now,
On Sat, 25 Mar 2006 11:46:58 +
Duncan Coutts [EMAIL PROTECTED] wrote:
On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
This is a valid issue, as ghc is only supplied upstream for linux
(some older versions available in mingw32).
I don't think this is right. All the
On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote:
On Sat, 25 Mar 2006 11:46:58 +
Duncan Coutts [EMAIL PROTECTED] wrote:
On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
This is a valid issue, as ghc is only supplied upstream for linux
(some older
On Sat, 25 Mar 2006 12:37:45 +
Duncan Coutts [EMAIL PROTECTED] wrote:
On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote:
On Sat, 25 Mar 2006 11:46:58 +
Duncan Coutts [EMAIL PROTECTED] wrote:
On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
On Saturday 25 March 2006 12:49, Diego 'Flameeyes' Pettenò wrote:
NetBSD, OpenBSD, GNU/kFreeBSD, GNU/Hurd, Solaris?
It's great that you and others are working on alternative platforms, but
regarding decisions which tools we use, our main platforms are of interest.
Everyone else should/has to
On Saturday 25 March 2006 16:08, Carsten Lohrke wrote:
I don't think it's
acceptable to base our decisions on platforms nearly no one is using.
I'll try to avoid a flame reminding when Linux was really used only by a few
geeks...
And I'm trying to avoid saying this, but the day was sucky and I
On Saturday 25 March 2006 19:50, Diego 'Flameeyes' Pettenò wrote:
This is the same line of thinking that makes people use flash or wmv
because it's the silly Linux users that has to adapt, Windows works fine
and similar.
It's not. Darcs is not proprietary, so you can make it work if you
Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST]
It sounds to me like the overlays would benefit of using git/cogito.
The Linux Kernel uses this DVCS to full affect. Pulling changes from
other repositories, and even receiving email patches pushed from
people not having their own
Luca Barbato wrote: [Sat Mar 25 2006, 05:16:57AM EST]
Please consider git and mercurial proxies, maybe nobody proposed it
yet but is relatively easy to provide it and it would be great since
gives you most of the goods from darks w/out the pain related of
building it.
Could you point to some
Aron Griffis wrote: [Sat Mar 25 2006, 06:00:49PM EST]
Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST]
It sounds to me like the overlays would benefit of using git/cogito.
The Linux Kernel uses this DVCS to full affect. Pulling changes from
other repositories, and even receiving
On Sat, Mar 25, 2006 at 06:00:49PM -0500, Aron Griffis wrote:
Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST]
It sounds to me like the overlays would benefit of using git/cogito.
The Linux Kernel uses this DVCS to full affect. Pulling changes from
other repositories, and even
On Sat, Mar 25, 2006 at 06:12:07PM -0500, Aron Griffis wrote:
I should backpedal on that statement a bit... While I think it's true
historically, git is doing a great job for kernel development, and it
can't be criticized lightly. Nonetheless, similar power is available
in other DVCSs that
Aron Griffis wrote:
Luca Barbato wrote: [Sat Mar 25 2006, 05:16:57AM EST]
Please consider git and mercurial proxies, maybe nobody proposed it
yet but is relatively easy to provide it and it would be great since
gives you most of the goods from darks w/out the pain related of
building it.
Fernando J. Pereda wrote: [Sat Mar 25 2006, 06:18:52PM EST]
Well, I find it easier to understand than many other DVCSs out there...
In fact I don't think it is difficult to use in any way. Maybe pre-1.1
versions had some syntax weirdnesses, but the 1.2 series are really easy
to use and
On Fri, 2006-03-24 at 22:47 -0800, Ryan Phillips wrote:
We need to pick one VCS and only one. Having multiple systems
requires users to install multiple applications and learn each one.
Not all of them are easy to pick up. Plus, it would be nice to be
able to merge from the overlays to the
Duncan Coutts wrote:
On Fri, 2006-03-24 at 22:47 -0800, Ryan Phillips wrote:
We need to pick one VCS and only one. Having multiple systems
requires users to install multiple applications and learn each one.
Not all of them are easy to pick up. Plus, it would be nice to be
able to merge from
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled where, and by whom? Are we
considering a fairly tightly controlled system, or a wild free-for-all?
Exactly which
Grant Goodyear wrote: [Fri Mar 24 2006, 02:35:34PM EST]
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled where, and by whom? Are we
considering a fairly tightly
On Friday 24 March 2006 14:35, Grant Goodyear wrote:
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled where, and by whom? Are we
considering a fairly tightly
On Friday 24 March 2006 15:06, Daniel Ostrow wrote:
On Friday 24 March 2006 14:35, Grant Goodyear wrote:
After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed. Who has read access?
Who has write access? Bugs are handled
Thanks for the summary. I think that's a fair assessment of where we are at.
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed a
preference for a
Stuart Herbert wrote:
Thanks for the summary. I think that's a fair assessment of where we are at.
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed
On Friday 24 March 2006 21:44, Stuart Herbert wrote:
The offered software will be trac, svn, and moinmoin. I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not. No-one has expressed a
preference for a different distributed VCS
43 matches
Mail list logo
