nmgeek wrote:
> I think adding text to identify the node type would really help people
> learn
> the symbology in the revision graph. Also, I don't see a copyfrom url
> in the
> roll-over popup.
>
> Here are a couple other comments after another day of using the
> revision
> graph:
>
> 5. I don't see any reason to have the button that turns on/of "Show
> HEAD revision nodes". Just show them all the time ... it would be one
> less button in the GUI to get confused about.
But some people don't like that node.
> 6. Also, whereas the highlight outline graphic which shows
> the current version in the working copy is _black_ for square nodes
> it is _grey_ for HEAD/eliptical nodes. The grey is hard to see ...
> it's hard to
> see it's there at all. It makes more sense to show it in black like
> with
> the other nodes.
Stefan^2 already made some changes there on his revision graph branch.
> 7. Are there supposed to be merge lines? I can see the branch lines
> but
> no merge lines.
No, merge lines are not implemented. Because Subversion doesn't provide
the APIs we would need for it. We could work around that and ask the
repo for the required info ourselves, but it would take a few seconds
for *each* revision - imagine the TSVN repo with > 10000 revisions: it
would take ages to get the graph.
> 8. It would be really helpful to show an additional node above the
> head
> node when the file is modified in the working copy.
Above the head? Your working copy can't be above the HEAD.
> 9. If you have the modified node displayed then you can add right-
> click
> menu command for "diff with HEAD" (for the modified node),
> "diff with previous version" for committed nodes, and a general "diff
> with selected node" which would really, really help you see what you
> are about to get into with an upcoming merge.
good idea.
> Maybe from these suggested enhancements you can see how the revision
> graph can be the _primary_ screen for exploring branched version
> history and
> understanding and executing merges.
>
> I have a process question: When you or Simon answer with
> something like "good point" should I interpret that as, "yeah
> I'll improve the documentation so this is addressed" or is it
> up to me to file an issue against the documentation to help insure
> its addressed in the documentation.
Yes. That means that we think it's a good idea and will
implement/improve/... that feature. It does not mean that we file an
issue for it though.
Speaking for myself: I usually move such mails to a special folder in my
mail client. Whenever I have time I go through that folder and pick some
task to do. Sometimes however if I start working on a task and then
realize that either the feature is not good or that it's not possible to
implement it (e.g., some API doesn't return the required info), then I
just drop it - but that doesn't happen often.
> I understand everyone is volunteering their time (even me
> in this case). I also understand that even volunteers
> like to follow a well defined process. So I'm (hopefully
> respectfuly) just checking in on the process.
Don't worry, you're doing it right :)
The reason I don't really like the issue tracker is that it's more work
than necessary. Keeping the corresponding mails in a separate folder is
much easier.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-09-04 21:16:26 CEST