On 10/2/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
>
> On 10/2/07, Joel Chen <whitegust@gmail.com> wrote:
> > On 10/2/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> > > On 10/1/07, Joel Chen <whitegust@gmail.com> wrote:
> > > > I suggest that TortoiseBlame and TortoiseMerge be combined together.
> > This
> > > > 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*.
Yes, that's what I wish to see during merging.
> > > Currently in TortoiseMerge I can only copy text from the left pane to
> > the
> > > > 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
> > file.
> >
> > 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?
Left view able to copy text to the right, and right view able to copy text
to the left. Have a try on WinMerge. There might be some features in
WinMerge you might find worth implementing on TortoiseMerge.
> > > Now we can compare revisions with 2 or more revisions apart by
> selecting
> > 2
> > > > revisions in the Revision Graph, or compare working copy with
> another
> > > > revision through right-click in the Log Messages, or selecting 2
> > revisions
> > > > in the Log Messages and compare them. Hence, Log Messages seems to
> have
> > more
> > > > control in comparing revisions than Revision Graph which is quite
> > ironical.
> > >
> > > 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
> trunk (http://svn.collab.net/repos/svn/trunk).
> 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.
I tried to display the revision graph for TortoiseSVN. A waiting popup with
"Getting information from repository" took more than 1 minute, while
"Analyzing data" took few seconds, plus a few seconds more with "Show all
revisions". I can see my CPU usage low but incoming packets rising high
during "Getting information from repository", meaning that it's network
speed rather than data analysis that's slowing the loading of revision
graph.
Every time I click to display the revision graph anew, I would have to go
through the waiting popup again. Could this "information from the
repository" be cached the 1st time so that on 2nd onwards whenever I want to
view the revision graph, it would skip to "Analyzing data" which costs only
few seconds?
I'm glad that you assured that the rendering speed of the graph is fast, and
ensuring the current implementation is better than the tree control.
Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: users-help@tortoisesvn.tigris.org
>
>
Cheers!
Joel
Received on Tue Oct 2 19:25:48 2007