Leonard Ritter wrote:
> 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?
Well if you submit a question to the mailing list, you *are* responsible
for looking there for the answer. It is right here:
> i'm not aware how to "check the results" using the command line client. what
> do you mean?
Do the equivalent operation using the subversion command line client and
see if you get the same error. If you don't already have the command
line client, you can download V1.2.0 from the subversion website. Look
up the 'svn merge' command in the subversion manual for details of how
to use it.
> 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:
If you are starting a new topic, please use a separate mail, otherwise
the mailing list threads get broken.
> 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
What do you mean by 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.
I suggest you find out why. Maybe that commit was on trunk or on the
wrong branch. Use the repo browser to get a log from higher up the tree
and see what actually happened in r711.
> 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
What you would like, and what everyone would like, is merge tracking.
That is on the subversion roadmap, but it is some way off yet.
> 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.
You are being bitten by the 'stop on copy' flag. Remember that
subversion does not (yet) do true renames. If you move a branch it is
effectively being deleted from its original location and added at the
new one. If you show log with the 'stop-on-copy' box checked, the log
will only go back as far as the last copy operation, ie. when you moved
that branch. Uncheck the box and click on 'Next 100' or 'Get all'.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jul 12 17:02:07 2005