On Apr 29, 2012, at 7:51 AM, Stefan Fuhrmann wrote:
> Another such case that I ran into recently is
> with reverse-merging changes. Those "un-merged"
> revisions seem not to re-appear on the "eligible
> for merge" list. Don't remember the specifics, though.
I seem to recall that that was a consc
Am 24.04.2012 22:27, schrieb Daniel Shahaf:
Stefan Fuhrmann wrote on Tue, Apr 24, 2012 at 22:20:52 +0200:
(2) Modified merges.
In case of textual conflicts, users will usually resolve them
before committing the merge result. Depending on policies,
a user may even need to modify textually success
Stefan Fuhrmann wrote:
> (2) Modified merges.
> In case of textual conflicts, users will usually resolve them
> before committing the merge result. Depending on policies,
> a user may even need to modify textually successful merges
> to e.g. fix a broken build before the merge may be committed.
>
(I'm using separate Subject lines for my replies to your two points.)
Stefan Fuhrmann wrote:
> (1) Renamed / moved nodes.
> [...] even *with* move support in the back-end,
> we could not rely on the mv command being used accurately
> and consistently [...] And there is lots of gray area where
> s
Stefan Fuhrmann wrote on Tue, Apr 24, 2012 at 22:20:52 +0200:
> (2) Modified merges.
> In case of textual conflicts, users will usually resolve them
> before committing the merge result. Depending on policies,
> a user may even need to modify textually successful merges
> to e.g. fix a broken build
Hi all,
This post is meant to document two pieces of information
that SVN does not track explicitly and how that effects
SVN's merge logic. I'm not an expert on the merge code
as we use it in SVN right now, so feel free to correct me
if some of the following is already being addressed.
Also, I'm
6 matches
Mail list logo
