On 6/5/06, Oscar Fuentes <oscarfv@telefonica.net> wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
>
> > What you are seeing here is the change "bubling up" to the root.
> > Since you are replacing one node revision of a file with another, we
> > need to update the parent directory with a reference to that new
> > revision. This, in turn, means that the parent has changed, and its
> > parent needs to be updated. This process continues up to the root.
>
> [snip]
>
> Peter,
>
> Thanks for your clear and informative answer. I'm afraid this is one
> of those things that needs a deep redesign to be fixed, so no hope for
> change soon.
>
> It's a bad bad thing that a commit causes a repository grow that is
> proportional to the number of files of (part of) the working copy.
It's not proportional to the number of files in the project, it's
proportional to the depth of the file you're changing. If you put
10,000 files in a single top-level directory, then changing a single
file would result in only 2 new nodes being created in the new
revision: the file itself, and the top-level directory. If you
change a file that's 20 levels deep within the repository, every
parent needs to be tweaked, so you'll see 21 new nodes created.
As others have already pointed out: it's a deliberate decision, not a
"deep design" bug. If we were to store directories compressed, it
would be *very* slow to access that file 20 levels deep.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 6 05:57:46 2006