[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

merging and switching

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-01-24 00:37:58 CET

At this point, I'm sure everyone saw the power-plant that was just
checked into notes. Karl is going to add some further thoughts.
Everybody take your time to digest that doc. :-)

But to start some conversation (assuming you've *read* the doc first),
here are a couple of questions on the table:

  1. In order to do a merge, the client must create two sets of
      fulltexts in some temporary area. It then makes context diffs
      between the fulltexts, and applies the diffs to your working
      copy as local mods. We've talked about just asking for the 2
      sets of fulltexts directly; we've also talked about doing fancy
      things to make the 2 sets of fulltexts "materialize" via binary
      diffs over the wire.
 
      Given how rarely merges occur, is it worth jumping through hoops
      to reconstruct the fulltexts? Maybe it's just simpler to have
      the client grab the fulltexts directly. What do people think?

  2. Last night Karl realized that we could just run

          'svn diff -r X:Y URL'

      and apply the context diffs right to our wc! In other words,
      Philip's fancy new diff-editor is already doing what we want.
      Cmpilato points out, however, that a *true* merge should be able
      to generate context diffs between any 2 arbitrary urls, which
      Philip's system can't yet do. Kfogel counters with the notion
      that for 99% of all merges, the two urls are identical anyway.

      So, what method to use? And, do we need to stay flexible and
      accept 2 different urls?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.