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.
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).
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.
similarly, as the poster stated, to get the same functionality, one would have to copy and paste every dialog window.
It's just surprising to me the apparent hostility that is thrown at a 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, 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?!
Peter
________________________________
From: Craig.Schroeder@thomson.com [mailto:Craig.Schroeder@thomson.com]
Sent: Wednesday, October 11, 2006 1:58 PM
To: users@tortoisesvn.tigris.org
Subject: RE: TortoiseSVN action logging.
Peter wrote:
> Hi,
>
> I reckon that anyone is able to cut-paste what is in that dialog, but that
> wasn't the them later (taking murphy's law into account , the only one needed will
> be forgotten), which is why a automatism comes into place.
> Regarding where the log should be saved, why not in the user's application data
> directory: C:\Documents and Settings\<USERNAME>\Application
> Data\TortoiseSVN ?
> I don't believe the save location would forcefully have to be configurable at start,
> but it would be a great idea.
> The log could be stored in .xml but I don't see where xml would be useful, text
> should do the trick , the rotation of the logfile could also be configurabe (as most
> application logs are) and its content too (being able to log
> commits/updates/checkouts independently could be useful, the commit log is always
> available from the standard log command for instance, and could be unselected by default).
> I am totally aware that the request is a bit vague, but as end-users, we can at best give you
> our input, but I believe that as tsvn devs, you have such a greater deal of experience with the
> product development that we do, that you sure are better at deciding those points.
> I hope this helps,
> --Peter.
On 10/11/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
Peter Scmsvn wrote:
> Hi,
>
> are there any tsvn devs that might have some insights on that remark ?
> Would it be possible to open a feature-addition ticket ?
Why would you need to log the actions? You can see them in the progress
dialog. If you need them for later, you can
Ctrl-A (to select all entries)
Open text editor
Ctrl-V (to paste the entries into the text editor)
Also, this request is incomplete as it doesn't answer the most basic
questions:
* 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
like?
* How long should the log be kept?
* Should the log be stored all in one folder, or in subfolders according
to the repository UUID?
Stefan
I don't entirely see the usefulness (I understand the concept of maintaining a log I just don't know why someone would use it -- and, I'm not trying to be sarcastic, if someone could share a use it would be helpful) of this feature since we have the 'Check for modifications' dialog, and the log would really have no bearing/authority on what is currently in a working copy.
Another question to throw into the mix, what should happen when two working copies on a machine are connecting to the same repository?
--Craig
Received on Wed Oct 11 23:26:39 2006