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

Re: Merging and switching

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-01-25 22:19:02 CET

Just want to clear my head about storing information about merge
sources. I know this isn't planned for M9, but I feel it's a feature a
lot of people will want.

(Just the other day I talked about CVS to our SE Process boss, and he
complained there was no way to find out which versions were merged
where, except by noting that in the log. Sound familiar?)

I'd vote for adding this feature sooner rather than later. Now there's
the questinon of how and where to store that info. Basically I see these
possibilities:

   1. store the URL+revision of each merge source in the target file's
      props (and /visa versa/)
      Pros: The info is independent of the FS implementation.
      Cons: It's very verbose, and potentially eats a lot of space.
   2. store the same info in the node FS as a list of (source/target)
      node IDs
      Pros: Compact representation, doesn't eat space in the WC
      Cons: Depends on the FS implementation; the client must
      specifically request the info to get it (that might actually be a
      pro, who knows)
   3. make a new kind of record in the database a "merge association",
      indexed by source and target node ID.
      Pros: Compact representation, and lots of metadata could be tagged
      on to the merge record
      Cons: Basically same as (2)

(Each of these possibilities has several variations, but that's the
basic idea.)

Fishing for comments ...

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
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:37:00 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.