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

Re: NTK on Subversion & others

From: <kfogel_at_collab.net>
Date: 2004-03-11 20:42:48 CET

Brad Appleton <brad@bradapp.net> writes:
> - Codeville boasts the ability to do "smart" merging in that it knows
> which sets of deltas have already been merged/applied and doesn't
> try to make you reconcile them again

Aaah. <jealousy>

> - Bitkeeper boasts the ability to give the "true" change-set that
> introduced some lines of code (e.g., in an annotated listing or
> diff). An example is in order ...
>
> In ClearCase and Perforce, it can be common practice to
> merge a task-branch to a development integration-branch,
> which might then be merged to a SCM and/or QA integration
> branch, and then finally "mainlined". When listing the
> contents on mainline "annotated" with the branch/task-id
> that introduced the change, sometimes ClearCase or Perforce
> will attribute the change to one of the several levels
> of integration branches it was merged/propagated thru
> instead of to the initial task branch that started the
> merge-propagation chain.
>
> BitKeeper claims it doesn't have this problem and will correctly
> identify the initiating branch/task-id that introduced the
> changes (rather than a subsequent one that simply merged them).
> I think it does this with a similar mechanism as Codeville, by
> associating a unique-id (e.g., cset-name) for each delta line
> of code.

Aaah. <jealousy>

Now I understand :-). Yes, I agree these are not exactly the same,
though it helps to have the latter to implement the former.

> I'm most interested in the "smart" merging (which someone
> posted a Perl script for a few days back), but wondered if
> the latter was easy to do (either as a result of doing what
> SVN already does, or if it was "trivial" once one had the
> smartmerge capability)

I would have thougt the other way around, but <shrug> not having
implemented either yet, can't really say.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 11 21:50:05 2004

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.