On Sep 4, 1:16 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> 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.
It took me a while to get back to this discussion: I was training an
office of IT folks
how to use TortoiseSVN.
I'm interested in persuing the creation of a merge API in subversion
would support implementation of merge arrows in the revision graph
view. What are you looking for here? Is there anyone you would
collaborating with on the Subversion project?
One nit from the training: After you do an TSVN->add the "+" icon
appears over the .svn folder (first folder in the list) until you
refresh the screen
to fix it.
I have more to add to this discussion but right now I want to get on
merge arrow API thing while I have some time available to work on it.
> > 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.
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
> < 1KViewDownload
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-09-18 21:53:41 CEST