On 3 May 2004, at 16:38, kfogel@collab.net wrote:
> Sure. I wasn't talking about persuading your boss to pay you for your
> time spent working on someone else's problem, but rather persuading
> him that it's okay (i.e, doesn't cost him anything) for other projects
> to use algorithms and code already written by his team.
>
Ah, ok. You're right I misunderstood that. Unfortunately my code is of
no use to subversion, because
-- its ruby
-- it's in memory (not streaming)
-- it's not production code and never will be
I'll have to stop on the topic soon-ish and move on to calendaring, but
I'll try and get our sponsors interested,
Thanks for the interest and the info with your patch adjusting. I've
though about that some more and now think that the problem that solves,
is one we don't have.
It really is specific to version control to merge (partial) changes
across branches. Even in distributed synchronisation always the whole
changes will be merged and a common ancestor created.
Also it is clear that the algorithm I showed, does not help for that
kind of use cases that are discussed in the link you sent.
But still, the approach of using copy and add instruction is the diff
and patch process should result in less conflicts. Even if you do it on
a line basis. But as I understand you use external patch, so that's out
of the question.
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 4 09:55:40 2004