> "Max Bowsher" <email@example.com> 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? :-)
Um? Consider either the locking, or the ruby branches. Both received merges
of all changes from trunk on a regular basis. That is the kind of branch to
which I was referring.
>> 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
I noticed a rather unpleasant slowdown in the speed of diffing the ruby
branch versus trunk as more merges were performed.
> 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
> 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.
I'm approaching this from the diff performance angle, rather than the space
angle, and my (admittedly subjective) experience with the ruby branch,
coupled with the a feel that diffing two copies of an entire tree of code
isn't going to be wonderfully quick... makes me think that the phenomenon is
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Apr 11 23:44:00 2005