[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: TortoiseSVN action logging.

From: Peter Yamamoto <yamamotop_at_page44.com>
Date: 2006-10-12 20:11:36 CEST

"Option to save the log" I meant the typical options associated with apps (not just p4) in the application's preferences.

As an example, P4v has these options in it's general preferences dialog:
Log all: [ ] (kind of weird, I don't know what "not all" covers)
Enable logging to file: [ ]
Log file Name: [ ] [select...]
Log file Size: [ ]kbytes

As another example, another app has these logging options:
[ ] on [ ] off
Filename [ ] [browse...]
Max size (bytes) [ ] (-1 indicates unlimited)
[ ] append (eg on application start/reset start a new log or append to existing)

I'm sure that several nice/desirable features could be suggested but the basic notion of a log file is, well, basic... Isn't it? I guess not. If that's the issue, I apologize for assuming too much.

As to not answering questions, um, I just started in this discussion. I think you may be mixing up posters. Regardless the questions you say haven't been answered were actually responded to recently (eg where save file etc).

Again, I think you take an adversial role in questioning the use of the log (which is fine, if there is reasonable doubt, but it's not fine if you're not really listening/putting yourself in another user's situation)...

Once again... my workspace state now, may have nothing to do with my workspace state 1 hour ago, much less 2 or more days ago. So if I want to go back and see activity, that's hardly reconstructable from the current state of the workspace. I don't understand why this concept is so hard to comprehend. You're arguments would seem to bring into the question logging of any application's activity, yet many applications provide this feature, is this so foreign?

For people who are doing a lot of merging, a lot of individual work, managing a lot of workspaces, having to prove that a particular file/folder/workspace was updated to a particular revision at some specific point in the past) having a log is very useful.

As for different repositories etc, I don't see where that even comes up. Viewed as application, it makes sense that there is one log file; again, it seems like the very notion of a log file for an application is starting from scratch (eg "what a weird concept") here... Kind of weird.

I would assume that the logging would illustrate what paths are being used to communicate with the server (otherwise it'd be pretty pointless).

Anyway, I feel that this issue has still not passed the "should it be considered at all" stage based on your arguments. Perhaps that should be established first so that other answers/comments aren't dismissed when they are there (eg the answers already posted that you suggest it was my obligation to supply).

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn@gmail.com]
Sent: Thursday, October 12, 2006 10:30 AM
To: users@tortoisesvn.tigris.org
Subject: Re: TortoiseSVN action logging.

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 is closed.
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 dialog.

> 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
> 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?

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: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Oct 12 20:11:45 2006

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.