Hi,
as the thread "starter" I have read throughoutfully your discussions which
are quite interesting.
I might be wrong, but I don't think we should argue on each other's attitude
(which is indeed what I am doing right now) as I think everyone is doing a
great job, even people requesting new features, that collaborative work has
made TSVN the leading windows SVN GUI and everyone is concious about that
notion and specifically what has been achieved by you devs (you know, we
might be using svn for development too;)).
Aside from that, I think it has been stated before, but the log file doesn't
need to be implemented as a feature which would be readable by a custom GUI
as for the TSVN log currently being implemented, I only see it as a simple
text file being incremented somewhere on the user's profile, not as a full
xml file with a GUI to interact with it, I do not think (and I really might
be wrong) that taking what the little post-action window states and putting
that in a file somewhere automatically, appending a bit of extra info as the
hour, repo path/UUID/whatever is overly complicated, but then if I'm wrong
it could only be noted as something to consider in future majors.
Regarding its use, it is seems very obvious to me (and sorry but I do not
think that my works habbits are _that_ bad ). For instance (and that is just
one example) it has happenned to me before to make some consecutive actions
locally, and well, then answer the phone or be distracted, and forget
exactly what I did and what the server answered, or what exact file was
merged locally etc... Of course, these would be local actions, as remote
ones are fully traceable by the current TSVN log GUI, but for every local
action that might have been done, some sort of log that would allow you not
to lose forever what was stated in that little post-action window could be
useful, so as to show/read/use it later in the way you want.
As for the technical details, I personnally have already given my opinion in
the second mail I did send to that mailing list, in response to stefan's
inquieries, but as the other Peter stated, I'm not sure we are passed the
point where the modification is even considered, and I'm not sure some of
those details should even be taken into account while considering if the
feature should be added (is it configurable, how long should it be kept etc.
those couuld be future improvements).
But anyways, maybe its just a comprehension problem, I have made it clear
now what I do see as a log, and the difference it is compared to the
full-featured GUI tsvn LOG (actually its not the same thing at all imho) so
I'll let you consider this, and If I have any other insights I'll let you
know.
Thanks,
--Peter
On 10/12/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
>
> Peter Yamamoto wrote:
> > "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.
>
> I'm not sure what other applications you use, but I just checked most of
> the apps I have installed on my machine, and there's maybe one which
> writes a log of its activities, and that's one which runs automatically
> in the background, so a logfile is the only thing you have.
>
> > 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).
>
> Sorry, but that mail arrived in my inbox five minutes ago. Don't know
> what happened, but when I read this I looked for a mail where you've
> answered the questions and couldn't find one. I even went online to
> check the mail in the web, and there I find it. One minute later I also
> had it in my inbox!?!
> So, again, sorry.
>
> > 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)...
>
> Hey hey, careful here. You're basically accusing me of not listening to
> users and be not connected to them! I really hate that - such
> accusations are too vague to really fight them with arguments, so drop
> that please.
>
> > 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?
>
> As I mentioned above, I don't know many applications which actually
> provide saving activities to a log file (server apps excluded).
>
> > 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.
>
> Useful for what? You tell here that 'it would be nice if' or 'would be
> very useful to have a log' - but I still don't know what you would need
> that log for. You say you don't know what files got updated anymore. Ok,
> I get that. But why do you need that information? Can't you just update
> the whole working copy again to make sure your working copy is at the
> latest revision? You might need to do that anyway before committing.
>
> If you may have missed a 'skipped' entry when merging, you really should
> change your working practice: if you don't look at the result of a merge
> but just assume everythings ok and go on, you will get into serious
> trouble sooner or later - whether you have a log of the merge or not.
> Because if you go on working on the wc, you will have a hard time
> getting your wc to compile correctly with all your own changes after the
> merge that you might be better off starting from scratch again.
>
> After a merge, the first thing you should do immediately is compile your
> project to see if everything is still ok. You don't know if the
> automatic merging may have changed something which breaks the build.
>
> When I read your example situations where you would need such a log
> (while I still don't get what exactly you would use the log for), I get
> the impression that your working style is a little bit chaotic. (Please
> don't take this the wrong way, it's just my impression, nothing personal).
>
> > 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.
>
> Different repositories may not be an issue for you. But many people work
> on several different projects, and therefore have working copies
> assigned to different repositories. Should we just log every action of
> all those different repositories into one big logfile? That may be
> confusing to those users.
>
> > I would assume that the logging would illustrate what paths are being
> > used to communicate with the server (otherwise it'd be pretty
> > pointless).
>
> As you may have noticed, most of the time the progress dialog only shows
> relative paths (relative to the working copy root or the path you
> started the operation on).
>
> > 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).
>
> You may not realize this, but your request requires a *lot* of work. And
> before I consider adding such a big feature with a lot of potential for
> many new bugs, I have to make sure that there's no other (better) way of
> doing what you want, and of course if that feature really is necessary.
>
> I thought that by using a version control system, you have all the log
> information you need. After all, the log dialog in TSVN is one of the
> two biggest dialogs (big in terms of lines of code) with a *lot* of
> functions and features. You can get almost every information out from
> it. So it's really hard for me to see why you need yet another log.
>
> Stefan
>
> --
> ___
> 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
>
>
Received on Thu Oct 12 22:48:41 2006