Peter Yamamoto wrote:
> As a comparison, consider the p4 gui clients.
> They have a log window (so you can see the commands and the responses
> from the server) and the option to save the log.
So it doesn't save the log automatically? You only have a menu/button to
save the log manually? That's something completely different than what
you requested TSVN should do.
> This can be helpful when you want to go back and look at your activity
> for various reasons and to double check what new files were actually
> updated in your workspace, which ones ended up in a conflicted state,
> which ones were "missing", "skipped" (if you hit ok too soon, how do you
> get that info back from you're workspace? you can't as far as i know).
Conflicted files are marked conflicted, even after the progress dialog
And during an update, there's no "skipped" or "missing", that can only
happen e.g. during a merge. And if that happens, the dialog will stay
open even if you configured it to close automatically.
> Yes, you could check file dates, file versions, for some of these
> conditions after the fact, but that is both tedious and error prone. It
> wouldn't/couldn't necessarily tell you that your update two days ago,
> got these particular 4 files, for example, and some other operation
> between the time you think about it could have modified more files etc.
To check what files got modified during an update, show the log for the
folder, then select the revisions you updated - then you can see all the
files which got modified during the update in the bottom part of the log
> similarly, as the poster stated, to get the same functionality, one
> would have to copy and paste every dialog window.
But if you just close the dialog, what prevents you from also just
deleting the log files? Ok, closing the dialog will be much easier to
do, but still...
> It's just surprising to me the apparent hostility that is thrown at a
Why do you think we're hostile? I simply stated that before you can just
go and file an issue that there's still a lot to discuss.
> person posting a feature request. The goal seems to be as much to shoot
> down the person making the request, or the request itself, rather than
> truly thinking about it... Eg what do other version control guis log,
Honestly, I don't use other version control UIs - I have enough to do
with TSVN as it is, I don't have the time to install other version
control systems and try them out. You could have mentioned p4 in your
first post for example.
> why could this be useful, etc. It seems pretty obvious to me that it's a
> reasonable request and that at least reasonable defaults could be made
> as a starting pointing with a request for feedback/comments. Isn't that
> how new features usually start? Why does the poster have to post a
> complete/detailed specification first time?!
Ok, now you've complained about my attitude here. Ok, I'm sorry!
But you still haven't even tried to answer my questions:
> Also, this request is incomplete as it doesn't answer the most basic
> * where would that log be saved to?
> * if the save location is configurable, what would be the default?
> * what format should the log be? xml? Text? What should the
> entries look
> * How long should the log be kept?
> * Should the log be stored all in one folder, or in subfolders
> to the repository UUID?
Or Craigs question below:
> Another question to throw into the mix, what should happen when two
> working copies on a machine are connecting to the same repository?
Until those questions are answered and discussed, there's no use in
filing an issue or start implementing this feature. We first have to
decide how we can even do it before we start doing it.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Oct 12 19:29:29 2006