thanks for the quick answer.
i'm sorry, for some reason that i'm not responsible for, stefans answer
didnt get through. my usual policy is resending a mail until it gets
through. can you please forward his mail to me?
i'm not aware how to "check the results" using the command line client. what
do you mean?
oh, btw, we've found a problem today with 1.2.0 suggesting an improper begin
revision for merging based on the log entry that was selected:
we had made a merge from a branch to the trunk in revision 700. after that,
several changes were made in this branch, including a one-time-file-change
in revision 711. now for some reason i have yet to make up, when i merged
the branch to the trunk a few revisions later (754), the log entry displayed
in the log for this branch right after the last merge log entry (700) was a
log entry from revision 736. the 711 log entry was not being displayed, god
knows why. stupid enough, my coworker was responsible for 711 so i wasnt
even aware that there should be a 711 revision. now of course, the happy
merger that i am, i selected the log entry (736) right after the last merge
log entry (700) and hit ok. the merge dialog used 735 as the last revision,
and 735 to head was merged from the branch into the trunk. 711 was not being
merged and my colleague later wondered where his changes are.
i remember that before 1.2.0, it was a bit different, although i forgot in
which way. what i would like is that i could select the last merge log entry
directly (700), and it would suggest 701. this way, the error wouldnt have
i'm aware that the actual problem that started it was log entry 711 not
showing up in the log, but the log behaves weird all the time. for example
we had the idea of moving branches that nobody is working on anymore to a
trash branch. when that was done (using the repo browser), the log for the
moved branch was inaccessible, showing only the last move as the only log
entry. but when i checked out that branch to a local directory and viewed
the log of the branch root folder using the context menu, the full log was
being displayed again.
of course, that also gave us major headaches when we had to merge back
changes from a branch that was already moved. it was impossible to directly
view the log in the merge dialog, but from above
check-out-and-see-log-of-local-folder-trick, we were able to determine the
correct revision and were also able to merge.
hope that helps.
From: Simon Large [mailto:firstname.lastname@example.org]
Sent: Tuesday, July 12, 2005 3:26 PM
Subject: Re: [TSVN] bug: when merging back newly added binary files, a
conflict is issued
Leonard Ritter wrote:
> we've been running into some problems with tortoiseSVN recently where
> binary files such as images that have been added to a subbranch create
> a conflict when the branch is merged back into the trunk.
You asked the exact same question on 7th July and received an answer from
Stefan within 2 hours in which you were asked to check the results using the
command line client. You *did* try with the CLI, didn't you?
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jul 12 16:02:04 2005