Re: Q: identical files "shared" in repository?

"Max Bowsher" <maxb@ukf.net> writes:
> Consider the case of merging of changes into a long running feature
> branch. Many files will be modified since the branchpoint, but many of
> those files will only ever receive merged changes, and so will be
> identical to a version on trunk.

We can't count on that. A branch file may receive only some merged
changes, and never be exactly identical to any particular trunk
revision (nor to any other branch revision). But why depend on
reasoning, when the facts are available? :-)

> It would be even nicer if subversion could notice this commonality
> when asked for a diff, and save time.

It would only be nice if it happens often enough to be worth the extra
code.

Gathering statistics on this would not be hard. I can't tell whether
or not you're arguing that that shouldn't be the first step, though.

> Also, consider the huge number of individual strings all holding the
> text "native" (i.e. svn:eol-style propvals) in a typical source code
> repository!

Sure, if we do this, it should be at the rep/string level, not at the
file/directory level. But that doesn't change the fact that the first
step is to get the facts, and only then to implement the change if the
facts warrant it.

Am I arguing against a straw man here? I just don't see any point
proceeding in design or coding of this until someone has analyzed a
repository and found that this phenomenon actually happens.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 11 22:57:43 2005