Clarifications on issue #504

["Eric W. Sink" <er...@sourcegear.com>]

The status page (http://subversion.tigris.org/project_status.html)
shows M9 including a task called "Merging", mentioned as issue #504.
Notes attached to that issue describe the task as "monstrous".

Could someone clarify exactly what will be needed to resolve this
issue?  Does "Merging" refer to the merging of branches, through
the use of an "svn merge" subcommand, implementing the behavior
of the -j flag in cvs?

In addition to my own ignorance, my confusion arises from
the perception that svn *already* supports "merging", in at least
one sense of the word.  After all, it appears to be shelling out
to call GNU patch to resolve conflicts during 'svn update' operations.

Surely issue 504 does not imply a reimplementation of patch?
Can we assume that subversion 1.0 final will still require the
presence of a separate patch program on the client side?

--
Eric W. Sink
eric@sourcegear.com
http://www.ericsink.com/





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

Re: Clarifications on issue #504

[Ben Collins-Sussman <su...@collab.net>]

"Eric W. Sink" <er...@sourcegear.com> writes:

> Could someone clarify exactly what will be needed to resolve this
> issue?  Does "Merging" refer to the merging of branches, through
> the use of an "svn merge" subcommand, implementing the behavior
> of the -j flag in cvs?

Hi Eric.

Yes, 'svn up' does work, and it does 'merge' a tree-delta sent from
the server into the working copy.  However: the tree-delta is always
between different revisions of the *same* directory.

But M9 will implement an 'svn merge' subcommand.  This is a fancier
version of update, because the tree-delta will now be comparing
arbitrarily different directories -- such as moving changes between a
'trunk' directory and some 'branch' directory.  And someday, we hope
to solve the 'repeated merge' problem (possibly by tracking
previously-merged changesets as properties, or somesuch.)


> Surely issue 504 does not imply a reimplementation of patch?

No.

> Can we assume that subversion 1.0 final will still require the
> presence of a separate patch program on the client side?

Yes, we should assume that.  Unless somebody can produce a non-GPLed
implementation of 'diff' and 'patch', we're stuck using the external
binaries.


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

Re: Clarifications on issue #504

[Karl Fogel <kf...@newton.ch.collab.net>]

"Eric W. Sink" <er...@sourcegear.com> writes:
> Could someone clarify exactly what will be needed to resolve this
> issue?  Does "Merging" refer to the merging of branches, through
> the use of an "svn merge" subcommand, implementing the behavior
> of the -j flag in cvs?

Exactly -- it's like "cvs update -j -j".

(We no longer think it's monstrously hard, just non-trivial.)

-K

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