Re: 3 way merge algorithm

[kf...@collab.net]

Torsten Rueger <to...@hiit.fi> writes:
> > Would it help if some of us sent letters saying how it
> > could make a real difference to our project if the restrictions were
> > lifted?  I'd certainly be happy to do so, if you think it would.
> 
> Thank's for the offer. But I don't think it would help. Our project is
> about data synchronisation, and while I have long seen the basic
> equivalence of source control and (multi-peer) synchronisation, my
> boss has not. So improving a source control system is at this point
> not on the agenda. I have been, and will continue to work on the issue
> though.

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.

Of course, we'd love to have as much of your time as possible, too... :-)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 3 way merge algorithm

[kf...@collab.net]

Branko Čibej <br...@xbc.nu> writes:
> >We use an internal diff/patch library now, in Subversion.
>
> To be pedantic, we don't actually use an internal patch
> implementation; that is, you can't apply a patch with "svn patch", or
> anything.

Sure.  What I meant was: since svn can update to receive repos changes
into a locally modified file, we clearly have some sort of internal
patch implementation.  Whether we call it "patch" or not, or make it
available as a subcommand, doesn't change that.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 3 way merge algorithm

[Branko Čibej <br...@xbc.nu>]

kfogel@collab.net wrote:

>Torsten Rueger <to...@hiit.fi> writes:
>  
>
>>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.
>>    
>>
>
>We use an internal diff/patch library now, in Subversion.
>  
>
To be pedantic, we don't actually use an internal patch implementation; 
that is, you can't apply a patch with "svn patch", or anything.

-- Brane




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 3 way merge algorithm

[kf...@collab.net]

Torsten Rueger <to...@hiit.fi> writes:
> 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.

We use an internal diff/patch library now, in Subversion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 3 way merge algorithm

[Torsten Rueger <to...@hiit.fi>]

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