Jan Kundrát wrote:
> Rémi Cardona wrote:
>> - svn uses a lot of disk space
>
> Could you please elaborate? Are you referring to the checkout size
> (which is about twice the actual size because SVN stores two copies of a
> file in the checkout to be able to perform diffs against latest revision
>
Side point: i am now aware that there is a better way to do this (pkgcore
cache/template.py and sql_template.py) thanks to ferringb.
--
gentoo-dev@gentoo.org mailing list
i appreciate that source control is needed to maintain files over a period
of time and to roll back changes. does that happen with ebuilds?
--
gentoo-dev@gentoo.org mailing list
Rémi Cardona wrote:
- svn uses a lot of disk space
Could you please elaborate? Are you referring to the checkout size
(which is about twice the actual size because SVN stores two copies of a
file in the checkout to be able to perform diffs against latest revision
without contacting the serve
Thanks for all the comments about the different SCM systems.
I'm a bit confused about all the portage tree stuff. Since a couple of us
were discussing a QA db on this list, I've been working on a script to pull
the info from the /usr/portage/ hierarchy. There's just under 25,000
ebuilds, which are
On Thu, Jan 18, 2007 at 07:52:23PM +0100, sanchan wrote:
> Markus Ullmann wrote:
> > This was one of the big reasons. They (and we maybe as well) have people
> > there with 56k/64k dialup connections. Checking out the whole thing
> > would take ages.
>
> I can confirm we have people with 56k dial
Markus Ullmann wrote:
> This was one of the big reasons. They (and we maybe as well) have people
> there with 56k/64k dialup connections. Checking out the whole thing
> would take ages.
I can confirm we have people with 56k dial up :-) Checking out portage every day
for a developer on 56k takes al
On Thu, Jan 18, 2007 at 12:09:30AM +0100, R?mi Cardona wrote:
> Because atomic commits don't exist in CVS, the scripts rely on
> commit/modification dates to recreate atomic commits in svn/git.
> Unfortunately, in some not-so-rare cases, it can definitely mess things
> up, and Gnome folks took abou
Steve Long wrote:
> Robin H. Johnson wrote:
>> My personal view (not infra) on it, is that I'm mostly negative about
>> changing VCS at all - I would prefer not to change, because the status
>> quo works very well as it is. If a change is going to be made, it should
>> be taken as a chance to resol
On Tue, Jan 16, 2007 at 05:36:34PM -0800, Donnie Berkholz wrote:
> The conversion to GIT from CVS was also lengthy (approximately two
> weeks) althought many projects attempted a switch this summer and
> tools have improved in speed.
Yes, the speed has increased a _lot_ now. In fact yesterday som
On Tue, 16 Jan 2007 16:12:21 +, Steve Long wrote:
> Robin H. Johnson wrote:
>> My personal view (not infra) on it, is that I'm mostly negative about
>> changing VCS at all - I would prefer not to change, because the status
>> quo works very well as it is. If a change is going to be made, it sh
On Wed, Jan 17, 2007 at 09:14:41AM +, Ciaran McCreesh wrote:
> | You get conflicts with CVS already in that case, it's not going to
> | increase the number of conflicts in any way.
> Except that with CVS, you just update that one directory, which isn't
> particularly painful even for all the ar
On Wed, 17 Jan 2007 01:06:31 -0800 "Robin H. Johnson"
<[EMAIL PROTECTED]> wrote:
| On Wed, Jan 17, 2007 at 08:38:34AM +, Ciaran McCreesh wrote:
| > | The other points were valid, but if it works anything like
| > | Gentoo, I think this is BS. Sure, everyone commits to the same
| > | tree, but n
On Wed, Jan 17, 2007 at 08:38:34AM +, Ciaran McCreesh wrote:
> | The other points were valid, but if it works anything like Gentoo, I
> | think this is BS. Sure, everyone commits to the same tree, but not to
> | the same lines of the same file. Unless all they do over in BSD-land
> | is globa
On Wed, Jan 17, 2007 at 09:03:59AM +0100, Markus Ullmann wrote:
> >1. Git currently requires you to check out the whole repository.
> > This includes *all of the history*.
> >2. Git cannot update portions of the repository, it can only update
> > the entire thing.
>
> This was one of the big r
On Wed, 17 Jan 2007 00:30:39 -0800 Donnie Berkholz
<[EMAIL PROTECTED]> wrote:
| Markus Ullmann wrote:
| > And the last thing was the idea about distribution. There is one
| > "centrally" maintained tree and people commit to it all day. So the
| > chance of getting conflicts in pushes if one is on
Markus Ullmann wrote:
And the last thing was the idea about distribution. There is one
"centrally" maintained tree and people commit to it all day. So the
chance of getting conflicts in pushes if one is on tour for three days
would be very likely and so the distributed part of the VCs wouldn't
Donnie Berkholz schrieb:
Greg KH wrote:
What was the reasons he cited?
Given that ports is pretty similar to our gentoo-x86, I'd guess about
the same ones mentioned at
http://dev.gentoo.org/~antarus/projects/gleps/glep-0666.txt -- I quote
from there:
1. Git currently requires you to check
Greg KH wrote:
On Wed, Jan 17, 2007 at 01:53:12AM +0100, Markus Ullmann wrote:
I've talked to a friend of mine recently. He's a FreeBSD dev and he said
they tried git for their ports tree (which is basically the same what
we're talking about) and it was more or less a big pain for multiple
rea
On Wed, Jan 17, 2007 at 01:53:12AM +0100, Markus Ullmann wrote:
> I've talked to a friend of mine recently. He's a FreeBSD dev and he said
> they tried git for their ports tree (which is basically the same what
> we're talking about) and it was more or less a big pain for multiple
> reasons.
> H
Steve Long schrieb:
I'm looking for a distributed SCM atm, and have come down to
git, bzr, svn or arch.
svn is centralized ;)
I'm leaning to git simply because it's used for the kernel, which seems
> like a project that would really stretch a VCS.
Well the kernel is quite large but doesn't
Robin H. Johnson wrote:
> My personal view (not infra) on it, is that I'm mostly negative about
> changing VCS at all - I would prefer not to change, because the status
> quo works very well as it is. If a change is going to be made, it should
> be taken as a chance to resolve as many different iss
22 matches
Mail list logo
