* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-09 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606091450180.5498@g5.osdl.org>
Apologies, I dropped out of the conversation -- Friday night drinks
(NZ timezone) took over ;-)
Now, back on track...
On 6/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
> In the meantime, the fact that git-cvsimport can be done incrementally
> means that once we have the silly pack-file-mapping details worked out, it
> should be perfectly fine to run the 3-day import just once, and then work
> on it incrementally afterwards without any real problems.
Exactly. The dog at this time is cvsps -- I also remember vague
promises from a list regular of publishing a git repo with cvsps2.1 +
some patches from the list.
In any case, and for the record, my cvsps is 2.1 pristine. It handles
the mozilla repo alright, as long as I give it a lot of RAM. I _think_
it slurped 3GB with the mozilla cvs.
I want to review that cvs2svn importer, probably to steal the test
cases and perhaps some logic to revamp/replace cvsps. The thing is --
we can't just drop/replace cvsimport because it does incrementals, so
continuity and consistency are key. All the CVS imports have to take
some hard decisions when the data is bad -- however it is we fudge it,
we kind of want to fudge it consistently ;-)
> So people like you who want to work on it off-line using a distributed
> system _can_ do so, realistically. Maybe not practically _today_
Other than "don't run repack -a", it's feasible. In fact, that's how I
use git 99% of the time -- to do DSCM stuff on projects that are using
CVS, like Moodle.
> The poor python/perl guys may write things more
> quickly, but when they hit a language wall, they hit it.
Flamebait anyone? ;-) It is a different kind of fun -- let's say that
on top of knowing the performance tricks (or, to be more hip: "design
patterns") for the hardware and OS, you also end up learning the
performance tricks of the interpreter/vm/whatever.
> > It would be better to rsync Martins copy, he has a lot more bandwidth.
I'm coming down to the office now to pick up my laptop, and I'll rsync
it out to our git machine (also NZ kernel mirror, bandwidth should be
good). That's one of the things I've discovered with these large
trees: for the initial publish action, I just use rsync or scp.
Perhaps I'm doing it wrong, but git-push doesn't optimise the
'initialise repo', and it take ages (and it this case, it'd probably
OOM).
> So it will take me quite some time to download 2GB+, regardless of how fat
> a pipe the other end has ;)
Right-o. Linus, Jon, can you guys then ping me when you have cloned it
safely so I can take it down again?
cheers,
martin
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Greg KH @ 2006-06-09 23:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091450180.5498@g5.osdl.org>
On Fri, Jun 09, 2006 at 02:57:58PM -0700, Linus Torvalds wrote:
> > It would be better to rsync Martins copy, he has a lot more bandwidth.
> > It will take over a day to copy it off my cable modem. I'm signed up
> > to get FIOS as soon as they turn it on in my neighborhood, it's
> > already wired on the poles.
>
> So it will take me quite some time to download 2GB+, regardless of how fat
> a pipe the other end has ;)
Fed-Ex a DVD or two would probably be fastest :)
^ permalink raw reply
* Redhat stateless Linux and git
From: Jon Smirl @ 2006-06-09 22:59 UTC (permalink / raw)
To: git
Redhat is looking for a scheme to sync the disk system of their
stateless Linux client. They were using rsync and now they are looking
at doing it with LVM.
What about using git?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 22:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091450180.5498@g5.osdl.org>
On Fri, 9 Jun 2006, Linus Torvalds wrote:
>
> Sure. I actually just have regular 128kbps DSL myself.
Not bits, bytes. 128_KB_/s, of course. Actually, it's slightly more.
Something like 146KB/s, I guess that comes to 1.5Mbps.
Just in case somebody thought I was living in a cave in the middle ages.
Anyway, no nice 5Mbps cable for me.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 21:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091356w391b4fdao23db5b2ce3c3e282@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> They need the distributed thing whether they realize it or not. Some
> of the external projects like songbird and nvu are vulnerable to drift
> since they are running their own repositories. Once a few
> move/renames happen they can't easily stay in sync anymore. It has
> been over a year since NVU was merged back into the trunk.
>
> That is the same reason I want it, so that I can work on stuff locally
> and have a repository. The core staff doesn't have this problem
> because they can make all the branches they want in the main
> repository.
Yes. Anyway, I think we'll get git working well for repositories that
size, and eventually the core developers will notice how much better it
is.
In the meantime, the fact that git-cvsimport can be done incrementally
means that once we have the silly pack-file-mapping details worked out, it
should be perfectly fine to run the 3-day import just once, and then work
on it incrementally afterwards without any real problems.
So people like you who want to work on it off-line using a distributed
system _can_ do so, realistically. Maybe not practically _today_, but I
don't think the git issues are serious enough that we'd be talking about
"months from now", but more of a "in a week or so we migh have something
that works fine for your case".
[ They had this long discussion about languages on #monotone the other
day, and the reason I'll take C over anything else any day is the fact
that a well-written C program is literally only limited by hardware,
never by the language. The poor python/perl guys may write things more
quickly, but when they hit a language wall, they hit it.
I think we've got an excellent data model, and handling even something
huge like the _whole_ history of mozilla doesn't look very daunting at
all. I just want to have a real test-case to motivate me to look at the
problems. ]
> It would be better to rsync Martins copy, he has a lot more bandwidth.
> It will take over a day to copy it off my cable modem. I'm signed up
> to get FIOS as soon as they turn it on in my neighborhood, it's
> already wired on the poles.
Sure. I actually just have regular 128kbps DSL myself. I guess I should
upgrade to 256 (the downside of having deer munching on the roses in our
back yard is that I don't think I even have the option for anything
faster), but I'm so damn well distributed that the slow 128kbps is
actually more than enough - everything serious I do is local anyway.
So it will take me quite some time to download 2GB+, regardless of how fat
a pipe the other end has ;)
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 21:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091655420.2703@localhost.localdomain>
On 6/9/06, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> > I haven't come up with anything that is likely to result in Mozilla
> > switching over to git. Right now it takes three days to convert the
> > tree. The tree will have to be run in parallel for a while to convince
> > everyone to switch. I don't have a solution to keeping it in sync in
> > near real time (commits would still go to CVS). Most Mozilla
> > developers are interested but the infrastructure needs some help.
>
> This is true. GIT is still evolving and certainly needs work to cope
> with environments and datasets that were never tested before. The
> Mozilla repo is one of those and we're certainly interested into making
> it work well. GIT might not be right for it just yet, but if you could
> let us rsync your converted repo to play with that might help us work on
> proper fixes for that kind of repo.
I'm rebuilding it on my shared hosting account at dreamhost.com. I'll
see if I can get it built before they notice and kill my process. My
account there is on a 4GB quad xeon box so hopefully it can convert
the tree faster. My account has 1TB download per month so rsync will
be ok. Not bad for $12 the first year.
It would take over a day to rsync it off from my home machine.
> > Martin has also brought up the problem with needing a partial clone so
> > that everyone doesn't have to bring down the entire repository.
>
> If it can be repacked into a single pack that size might get much
> smaller too.
>
>
> Nicolas
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Failed git commands and StGIT
From: Petr Baudis @ 2006-06-09 21:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0606091405o79002a79id02e8fdd3936a345@mail.gmail.com>
Dear diary, on Fri, Jun 09, 2006 at 11:05:47PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> I also found this annoying but I was too lazy to fix it. To not
> capture the stderr is easy (just change pass false as the 2nd argument
> to popen2.Popen3) but there is a duplicate of error messages from both
> GIT and StGIT. The other option is to add a '--verbose' option to most
> of the commands. I'll have a look at it this weekend.
I don't think this is actually an issue. I'd actually prefer the
behaviour of NOT having to add a '--verbose' option to a stgit command
to see the full error output.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Junio C Hamano @ 2006-06-09 21:06 UTC (permalink / raw)
To: Post, Mark K; +Cc: Linus Torvalds, git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507957896@usahm236.amer.corp.eds.com>
"Post, Mark K" <mark.post@eds.com> writes:
> Since umask isn't an environment variable, per se, I'm not sure how this
> will change anything.
I do not configure my sshd, so you may need a bit more reading
on it yourself; $HOME/.ssh/environment does not seem to be it,
as you said.
> One other thing I noticed is that init-db.c spells core.sharedRepository
> with a capital R, but setup.c spells it "core.sharedrepository" with no
> upper case letters. Would this make any difference to anything I'm
> seeing?
The distinction should not matter since the code downcases
(git_config_set_multivar() in config.c) it, but to avoid future
confusion we might want to downcase the one in init-db.c
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Nicolas Pitre @ 2006-06-09 21:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linus Torvalds, Martin Langhoff, git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
> I haven't come up with anything that is likely to result in Mozilla
> switching over to git. Right now it takes three days to convert the
> tree. The tree will have to be run in parallel for a while to convince
> everyone to switch. I don't have a solution to keeping it in sync in
> near real time (commits would still go to CVS). Most Mozilla
> developers are interested but the infrastructure needs some help.
This is true. GIT is still evolving and certainly needs work to cope
with environments and datasets that were never tested before. The
Mozilla repo is one of those and we're certainly interested into making
it work well. GIT might not be right for it just yet, but if you could
let us rsync your converted repo to play with that might help us work on
proper fixes for that kind of repo.
> Martin has also brought up the problem with needing a partial clone so
> that everyone doesn't have to bring down the entire repository.
If it can be repacked into a single pack that size might get much
smaller too.
Nicolas
^ permalink raw reply
* Re: Failed git commands and StGIT
From: Catalin Marinas @ 2006-06-09 21:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060609183623.GJ11941@pasky.or.cz>
On 09/06/06, Petr Baudis <pasky@suse.cz> wrote:
> a user at #git just came with a problem with stg refresh - it turned
> out that he did not have his environment set up properly, but what is
> troublesome that stg refresh just said that "git-commit-tree failed" and
> did not show the actual error message - looking at the code, you
> probably want to keep fd 3 on the parent process' stderr, that is use
> open2, not open3.
I also found this annoying but I was too lazy to fix it. To not
capture the stderr is easy (just change pass false as the 2nd argument
to popen2.Popen3) but there is a duplicate of error messages from both
GIT and StGIT. The other option is to add a '--verbose' option to most
of the commands. I'll have a look at it this weekend.
Thanks.
--
Catalin
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Jakub Narebski @ 2006-06-09 21:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606091344010.5498@g5.osdl.org>
I've put proposed solution in GitWiki:
http://git.or.cz/gitwiki/GitFaq#git-push-ssh-umask
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091331170.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > I haven't come up with anything that is likely to result in Mozilla
> > switching over to git. Right now it takes three days to convert the
> > tree. The tree will have to be run in parallel for a while to convince
> > everyone to switch. I don't have a solution to keeping it in sync in
> > near real time (commits would still go to CVS). Most Mozilla
> > developers are interested but the infrastructure needs some help.
>
> Sure. That said, I pretty much guarantee that the size issues will be much
> much worse for any other distributed SCM.
>
> If Mozilla doesn't need the distributed thing, then SVN is probably the
> best choice. It's still a total piece of crap, but hey, if crap (==
> centralized) is what people are used to, a few billion flies can't be
> wrong ;)
They need the distributed thing whether they realize it or not. Some
of the external projects like songbird and nvu are vulnerable to drift
since they are running their own repositories. Once a few
move/renames happen they can't easily stay in sync anymore. It has
been over a year since NVU was merged back into the trunk.
That is the same reason I want it, so that I can work on stuff locally
and have a repository. The core staff doesn't have this problem
because they can make all the branches they want in the main
repository.
> If you got your import done, is there some place I can rsync it from, and
> at least I can make sure that everything works fine for a repo that size..
> One day the Mozilla people will notice that they really _really_ want the
> distribution, and they'll figure out quickly enough that SVK doesn't cut
> it, I suspect.
It would be better to rsync Martins copy, he has a lot more bandwidth.
It will take over a day to copy it off my cable modem. I'm signed up
to get FIOS as soon as they turn it on in my neighborhood, it's
already wired on the poles.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Post, Mark K @ 2006-06-09 20:52 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git
Since umask isn't an environment variable, per se, I'm not sure how this
will change anything.
One other thing I noticed is that init-db.c spells core.sharedRepository
with a capital R, but setup.c spells it "core.sharedrepository" with no
upper case letters. Would this make any difference to anything I'm
seeing?
Mark Post
-----Original Message-----
From: Linus Torvalds [mailto:torvalds@osdl.org]
Sent: Friday, June 09, 2006 4:44 PM
To: Junio C Hamano
Cc: git@vger.kernel.org; Post, Mark K
Subject: Re: Git-daemon messing up permissions for gitweb
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> But that should be tweakable by configuring what sshd does for
> the user, shouldn't it? The "LOGIN PROCESS" section from man
> sshd(8) seems to talk about $HOME/.ssh/environment, for example.
Yeah. That's probably the right place to set things up.
Linus
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Post, Mark K @ 2006-06-09 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I'm fairly familiar with SSH, but I don't know how to do this. I just
did some man commands, didn't see anything there. Can you give me a
pointer?
Mark Post
-----Original Message-----
From: Junio C Hamano [mailto:junkio@cox.net]
Sent: Friday, June 09, 2006 4:19 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: Git-daemon messing up permissions for gitweb
"Post, Mark K" <mark.post@eds.com> writes:
> Martin is using git over SSH. I have git-shell in /etc/passwd for his
> account.
Ah, then umask git-shell gets from sshd is too restrictive.
Loosen it and you will be fine.
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jakub Narebski @ 2006-06-09 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
Jon Smirl wrote:
> Martin has also brought up the problem with needing a partial clone so
> that everyone doesn't have to bring down the entire repository. A
> trunk checkout is 340MB and Martin's git tree is 2GB (mine 2.7GB). A
> kernel tree is only 680M.
Partial/shallow nor lazy clone we don't have (although there might be some
shallow clone partial solutions in topic branches and/or patches flying
around in git mailing list). Yet.
But you can do what was done for Linux kernel: split repository into current
and historical, and you can join them (join the history) if needed using
grafts. And even if one need historical repository, it is neede to
clone/copy only _once_. With alternatives (using historical repository as
one of alternatives for current repository) someone who has both
repositories does need only a little more space, I think, than if one used
single repository.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Linus Torvalds @ 2006-06-09 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Post, Mark K
In-Reply-To: <7vodx2m5jp.fsf@assigned-by-dhcp.cox.net>
On Fri, 9 Jun 2006, Junio C Hamano wrote:
>
> But that should be tweakable by configuring what sshd does for
> the user, shouldn't it? The "LOGIN PROCESS" section from man
> sshd(8) seems to talk about $HOME/.ssh/environment, for example.
Yeah. That's probably the right place to set things up.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-09 20:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, git
In-Reply-To: <9e4733910606091317p26d66579mdf93db293f93fb50@mail.gmail.com>
On Fri, 9 Jun 2006, Jon Smirl wrote:
>
> > Git is much better at packing than either CVS or SVN. Get used to it ;)
>
> The git tree that Martin got from cvsps is much smaller that the git
> tree I got from going to svn then to git. I don't why the trees are
> 700KB different, it may be different amounts of packing, or one of the
> conversion tools is losing something.
.. or one of them is adding something.
For example, it may well be that cvs2svn does a lot more commits or
something like that.
That said, I don't even see where git-svn packs anythign at all, and
you're absolutely right that when/how you repack can make a huge
difference to disk usage, much more so than any importer details.
> > Do you have all the cvsps patches? There's a few important ones floating
> > around, and David Mansfield never did a 2.2 release..
>
> I am running cvsps-2.1-3.fc5 so I may be wasting my time. Error out is
> 535MB now.
> He sent me some git patches, but none for cvsps.
I've got a couple, but I was hoping David would do a cvsps-2.2. I have
this dim memory of him saying he had done some other improvements too.
> I haven't come up with anything that is likely to result in Mozilla
> switching over to git. Right now it takes three days to convert the
> tree. The tree will have to be run in parallel for a while to convince
> everyone to switch. I don't have a solution to keeping it in sync in
> near real time (commits would still go to CVS). Most Mozilla
> developers are interested but the infrastructure needs some help.
Sure. That said, I pretty much guarantee that the size issues will be much
much worse for any other distributed SCM.
If Mozilla doesn't need the distributed thing, then SVN is probably the
best choice. It's still a total piece of crap, but hey, if crap (==
centralized) is what people are used to, a few billion flies can't be
wrong ;)
If you got your import done, is there some place I can rsync it from, and
at least I can make sure that everything works fine for a repo that size..
One day the Mozilla people will notice that they really _really_ want the
distribution, and they'll figure out quickly enough that SVK doesn't cut
it, I suspect.
Linus
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Junio C Hamano @ 2006-06-09 20:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Post, Mark K
In-Reply-To: <Pine.LNX.4.64.0606091321100.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 9 Jun 2006, Post, Mark K wrote:
>>
>> Martin is using git over SSH. I have git-shell in /etc/passwd for his
>> account.
>
> Ahh. git-shell doesn't read .bashrc or anything like that.
But that should be tweakable by configuring what sshd does for
the user, shouldn't it? The "LOGIN PROCESS" section from man
sshd(8) seems to talk about $HOME/.ssh/environment, for example.
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Post, Mark K @ 2006-06-09 20:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
I'm not a C programmer, so I'm not sure exactly how to do what you want.
Is this right (it compiles)?
--- shell.c.orig 2006-05-15 16:01:37.000000000 -0400
+++ shell.c 2006-06-09 16:26:24.619808905 -0400
@@ -31,7 +31,7 @@
{
char *prog;
struct commands *cmd;
-
+ umask(0022);
/* We want to see "-c cmd args", and nothing else */
if (argc != 3 || strcmp(argv[1], "-c"))
die("What do you think I am? A shell?");
I won't be able to report success or failure today. Martin's in Germany
and I think he has a life.
Mark Post
-----Original Message-----
From: Linus Torvalds [mailto:torvalds@osdl.org]
Sent: Friday, June 09, 2006 4:22 PM
To: Post, Mark K
Cc: Junio C Hamano; git@vger.kernel.org
Subject: RE: Git-daemon messing up permissions for gitweb
On Fri, 9 Jun 2006, Post, Mark K wrote:
>
> Martin is using git over SSH. I have git-shell in /etc/passwd for his
> account.
Ahh. git-shell doesn't read .bashrc or anything like that.
Does adding a "umask(0022)" to the beginning of main() in shell.c fix it
for you?
Linus
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Linus Torvalds @ 2006-06-09 20:22 UTC (permalink / raw)
To: Post, Mark K; +Cc: Junio C Hamano, git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF41050795787F@usahm236.amer.corp.eds.com>
On Fri, 9 Jun 2006, Post, Mark K wrote:
>
> Martin is using git over SSH. I have git-shell in /etc/passwd for his
> account.
Ahh. git-shell doesn't read .bashrc or anything like that.
Does adding a "umask(0022)" to the beginning of main() in shell.c fix it
for you?
Linus
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Junio C Hamano @ 2006-06-09 20:18 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF41050795787F@usahm236.amer.corp.eds.com>
"Post, Mark K" <mark.post@eds.com> writes:
> Martin is using git over SSH. I have git-shell in /etc/passwd for his
> account.
Ah, then umask git-shell gets from sshd is too restrictive.
Loosen it and you will be fine.
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-09 20:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606091158460.5498@g5.osdl.org>
On 6/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Fri, 9 Jun 2006, Jon Smirl wrote:
> >
> > That looks too small. My svn git import is 2.7GB and the source CVS is
> > 3.0GB. The svn import wasn't finished when I stopped it.
>
> Git is much better at packing than either CVS or SVN. Get used to it ;)
The git tree that Martin got from cvsps is much smaller that the git
tree I got from going to svn then to git. I don't why the trees are
700KB different, it may be different amounts of packing, or one of the
conversion tools is losing something.
Earlier he said:
>git-repack -a -d but it OOMs on my 2GB+2GBswap machine :(
> > My cvsps process is still running from last night. The error file is
> > 341MB. How big is it when the conversion is finished? My machine is
> > swapping to death.
>
> Do you have all the cvsps patches? There's a few important ones floating
> around, and David Mansfield never did a 2.2 release..
I am running cvsps-2.1-3.fc5 so I may be wasting my time. Error out is
535MB now.
He sent me some git patches, but none for cvsps.
> I'm pretty sure Martin doesn't run plain 2.1.
I haven't come up with anything that is likely to result in Mozilla
switching over to git. Right now it takes three days to convert the
tree. The tree will have to be run in parallel for a while to convince
everyone to switch. I don't have a solution to keeping it in sync in
near real time (commits would still go to CVS). Most Mozilla
developers are interested but the infrastructure needs some help.
Martin has also brought up the problem with needing a partial clone so
that everyone doesn't have to bring down the entire repository. A
trunk checkout is 340MB and Martin's git tree is 2GB (mine 2.7GB). A
kernel tree is only 680M.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: Git-daemon messing up permissions for gitweb
From: Post, Mark K @ 2006-06-09 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Martin is using git over SSH. I have git-shell in /etc/passwd for his
account.
Mark Post
-----Original Message-----
From: Junio C Hamano [mailto:junkio@cox.net]
Sent: Friday, June 09, 2006 3:51 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: Git-daemon messing up permissions for gitweb
"Post, Mark K" <mark.post@eds.com> writes:
> I'm trying to set up a git repository for mainframe Linux developers
to
> use at git390.osdl.marist.edu. Everything _seemed_ to go well, until
> Martin Schwidefsky started actually pushing changes back to the
> repository. When he does that, the projects disappear from the web
page
> that gitweb.cgi is generating.
> As far as I can tell, the problem is happening because these files are
> being written out with file permissions of 640, and since Apache is
> running as user wwwrun, it can't read them:
> -rw-r----- 1 sky git 5490 Jun 9 03:35 ./linux-2.6.git/info/refs
> -rw-r----- 1 sky git 54 Jun 9 03:35
> ./linux-2.6.git/objects/info/packs
> -rw-r----- 1 sky git 41 Jun 9 03:35
First of all, it is not git-daemon that is updating these refs.
The daemon is a read only facility.
And you have checked the suggestion by Linus to set the umask to
world readable, which brings me to the next question.
How did Martin actually "push changes back"?
Was it over git protocol over SSH, or the webdav thing over http
push? The comment by Linus is about the former and I do not
know offhand who webdav thing runs as or how it handles the
permissino bits.
It could be that your ssh daemon installation bypasses .bashrc
and uses its own .ssh/environment, in which case your user would
may need to do umask there as well.
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Junio C Hamano @ 2006-06-09 20:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Post, Mark K
In-Reply-To: <Pine.LNX.4.64.0606091201210.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 9 Jun 2006, Post, Mark K wrote:
>>
>> As far as I can tell, the problem is happening because these files are
>> being written out with file permissions of 640, and since Apache is
>> running as user wwwrun, it can't read them:
> Or add
> [core]
> SharedRepository = true
>
> to the repository config file.
This is about being able to share among the group, not with
people outside, so if wwwrun is outside git group like Mark's
setting I do not think it would do anything helpful to the
situation.
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Junio C Hamano @ 2006-06-09 19:51 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF41050795782F@usahm236.amer.corp.eds.com>
"Post, Mark K" <mark.post@eds.com> writes:
> I'm trying to set up a git repository for mainframe Linux developers to
> use at git390.osdl.marist.edu. Everything _seemed_ to go well, until
> Martin Schwidefsky started actually pushing changes back to the
> repository. When he does that, the projects disappear from the web page
> that gitweb.cgi is generating.
> As far as I can tell, the problem is happening because these files are
> being written out with file permissions of 640, and since Apache is
> running as user wwwrun, it can't read them:
> -rw-r----- 1 sky git 5490 Jun 9 03:35 ./linux-2.6.git/info/refs
> -rw-r----- 1 sky git 54 Jun 9 03:35
> ./linux-2.6.git/objects/info/packs
> -rw-r----- 1 sky git 41 Jun 9 03:35
First of all, it is not git-daemon that is updating these refs.
The daemon is a read only facility.
And you have checked the suggestion by Linus to set the umask to
world readable, which brings me to the next question.
How did Martin actually "push changes back"?
Was it over git protocol over SSH, or the webdav thing over http
push? The comment by Linus is about the former and I do not
know offhand who webdav thing runs as or how it handles the
permissino bits.
It could be that your ssh daemon installation bypasses .bashrc
and uses its own .ssh/environment, in which case your user would
may need to do umask there as well.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox