Re: Tags and scalability (was Re: Enlightenment)

Hmmm, after minor research, looking at the LKML faq 1.10:

http://kernel.org/pub/linux/docs/lkml/#s1-10

See the second bulletted item.

If you go track down the original e-mail of the guy who suggested it, he
tweaked emacs to make backup files very similar to the way patch does.
Greg's right, emacs doesn't do that by default.... Sorry didn't mean to
disparage that fine editor emacs...

I figured I can teach my editor (vim) to do the right thing if a
.svn/entries file existed in the directory of the file I was editing. I
wasn't advocating using --hard-link in all cases, merely when the user
feels it can be handled by them. It would be a pretty healthy space
savings for me in a lot of cases. I'd much rather deal with that then
wait for several minutes on a check out of a big tree.

I thought the .svn/entries file contained enough information to realize
they'd done something that wasn't right, because the modification date
of the text base would change if they had used the hardlink via
open/write, and that wouldn't match the one in .svn/entries. I'm
suddenly realizing that this information might not be in there. I
thought it was to detect corruption along with the checksum. At this
point, they follow the standard procedure to recover from corruption,
and realize they shouldn't use --hard-link anymore.

My time is expensive, it's bad enough I have to wait for two copies to
be written on check out. I'd really rather not wait for compression on
top of that. It'll take longer then two copies... if hardlinks worked,
I'd much rather that then wait on a gzip on checkouts and base text
comparisions... Especially by default. Hardlinks have the advantage of
making the wc grow by roughly proportional change the user has made.

I'd still advocate it for the text bases in the svn cp file:// file://
because subversion should be the only modifier of the text base copies.
Then at least, I wouldn't have to pay twice for every tree. I'd only
pay twice for the first, and then only pay a for files that have been
modified since the svn cp happened. I can understand why this could be
seen as too much work.

You answered my question on why it's bad... I get it now. Sorry for the
mis-information. Bit Keeper gets away with it, because you do a bk edit
on the file first, which I'll bet will fix you right up for no
hardlinks... I know it was a requested feature of a Linux Kernel
maintainer for BK.

        Thanks,
                Kirby

On Fri, 2002-09-27 at 17:34, Greg Hudson wrote:
> On Fri, 2002-09-27 at 18:29, Ben Collins wrote:
> > If I see an editor that does "unlink/open/write" I think I'll stay clear
> > of that editor (and if emacs does that, maybe it's why I have steered
> > clear of it).
>
> Nope:
>
> error-messages% cd /tmp
> error-messages% echo foo > bar
> error-messages% ln bar baz
> error-messages% emacs -q -nw bar # Add 'b' to end of line
> error-messages% cat bar baz
> foob
> foob
>
> So you'll have to find some other reason to justify your irrational
> dislike of emacs. :)
>
> (emacs 21.1.1. I don't see anything in apropos for changing the
> behavior with regard to hard links, either.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org