Re: cygwin, 44k files: how to commit only index?
- From
- Torgil Svensson <torgil.svensson@gmail.com>
- Date
- Dec 9, 2006, 08:27 UTC
- Message-ID
- <e7bda7770612090027x22a06ca5i6d9b768f0ad3c4ad@mail.gmail.com>
- In-Reply-To
- <46d6db660612071326m4817165l992e8d6e7bd673c5@mail.gmail.com>
On 12/7/06, Christian MICHON <christian.michon@gmail.com> wrote:
Show 9 quoted lines
> On 12/7/06, Shawn Pearce <spearce@spearce.org> wrote: > > Shawn Pearce <spearce@spearce.org> wrote: > > > Its Cygwin/NTFS. lstat() is slow. readdir() is slow. I have the > > > same problem on my Cygwin systems. > > > > Just to be clear, I'm not trying to blame Cygwin here. > > > > Windows' dir command is slow. Windows Explorer is slow while > > browsing directories.
I think this is a very common scenario costing hideous amounts of money around the globe.
If you have lot's of files in a folder, don't even think of accidentally touching those folders in Windows Explorer, if you do - keep Process Explorer or similar ready. I've ended up using (even w/o Cygwin) scripts, automatic compressing and even a database functioning as directory cache - basically creating accessibility layers for a disabled file-system.
Show 25 quoted lines
> > before buying any new hardware, you could easily imagine the > following scenario (I'm also "stuck" with windows, so it's an idea > I've been toying around for a week or so). > > There're virtualizers around, on which networking capabilities can > be activated. And we could easily create a vm with linux+git > inside, using ext2/ext3/ext4 fs virtual disks (you'd benefit from > windows cache actually...) > > example: YTech_Subversion_Appliance_v1.1 (ubuntu + subversion). > > I've no prototype yet, but I've 2 scenario possible: > 1) use vmplayer and a minimal uclibc initramfs with git onboard > 2) use qemu+kqemu and a similar mini-distro (but right now networking > is an issue on windows hosts: I'm exploring tunneling) > > The 1st scenario is "easy". And I start to prefer this idea over > even mingw porting of git (I tried and it's hard, really). > > But again, maybe jgit would be a better universal solution. > > -- > Christian > -
Very interesting! Have you a time-frame for this? Maybe even