On 10/2/07, Joel Chen <firstname.lastname@example.org> wrote:
> On 10/2/07, Stefan Küng <email@example.com> wrote:
> > On 10/1/07, Joel Chen <firstname.lastname@example.org> wrote:
> > > I suggest that TortoiseBlame and TortoiseMerge be combined together.
> > > way we would have greater sight on overall changes. I had read about the
> > > Merge Tracking on the upcoming Subversion 1.5. It would be nice when
> > > TortoiseBlame and TortoiseMerge work together along with Merge Tracking.
> > What does blame has to do with diff? How would you combine those
> > completely different and unrelated tools? What would be the connection
> > between those two?
> > What would you gain by this feature?
> Hi Stefan, sorry to have caused much trouble to you with my suggestions. My
> thoughts were to have a view of who modified which lines and when in
> TortoiseMerge, so that developers can check who last modified a particular
> line when merging.
You can already see that when you 'diff with blame' from the log
dialog. But only there. Because a diff requires *two* revisions, while
blame only requires *one*.
> > > Currently in TortoiseMerge I can only copy text from the left pane to
> > > right pane. It would be more developer-friendly when it could be done
> > > vice-versa. A great merge tool for reference is WinMerge, available at
> > > http://winmerge.org.
> > There's a button/menu entry which lets you swap the left and the right
> Yes, this swap button is good feature, but I would prefer to be able to copy
> text from both sides.
Copy text from both sides? Do you mean copy text to the clipboard?
That's already possible. Do you mean copying text to the left view and
save that file? Just swap the views with the button and save it as the
right view. Where's the difference?
> > > Now we can compare revisions with 2 or more revisions apart by selecting
> > > revisions in the Revision Graph, or compare working copy with another
> > > revision through right-click in the Log Messages, or selecting 2
> > > in the Log Messages and compare them. Hence, Log Messages seems to have
> > > control in comparing revisions than Revision Graph which is quite
> > You're statement is correct. But what's your point?
> > Keep in mind thought that the revision graph is a *graph* and not a
> > tool to work with. For most projects, it simply takes too long to even
> > show the graph - the log dialog is faster and should be used for
> > anything else than showing a graph.
> Okay, now I see that your graph is aimed to be graphical and consists of
> rendering symbols and texts at the moment. The rendering could be what's
> causing a long time to display. That's a major drawback of the graph.
> Correct me if I'm wrong.
The rendering is pretty fast. It's the analyzation part that takes a
very long time.
> > Since when can explorer show a graph?
> > I'm starting to wonder if you even know how the revision graph is
> > generated or what it actually shows you? You know that it doesn't show
> > you the same information as the log dialog?
> My idea is to have a revision tree instead of a revision graph. A tree view
> to organise all the connections in the graph.
That's simply not possible. The revision graph is *not* a tree.
And please, do me a favour: show the graph once for the TortoiseSVN
trunk (http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk). Ok, now
imagine that data shown as a tree control.
Now, to make it a little more obvious, do the same with the Subversion
And of course, don't forget to enable the "show all revisions" menu.
I hope you can see the problem with our tree-view approach.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Oct 2 15:36:35 2007