Steve,
First of, please note that I am quite a fan of the way you are currently
maintaining and developing TSVN. A great product and lighting fast response
to every type of problem/suggestion that is posted here.
On 26/01/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
>
> Matthias Wächter wrote:
> >> Do you know that this would increase my workload at least by a factor
> >> of two? Most of these bugs are very small and fixed in no time.
> >> Creating an entry in the issuetracker would take sometimes more time
> >> than to fix a bug.
> >
> > Sure. That's my very generic point of view. I think co-developers of the
> > product automatically have a better overview than any user: They know
> > the code already, they sometimes review commits (rev-diff
> > notifications), they follow the mailing list(s) in general and may have
> > followed the discussions about the bugs. All a user can see at the first
> > place is the change log.
>
> Right. But the normal user doesn't care how a bug got fixed or the very
> details about it.
+1.
If a user is interested enough, he will read the commit log messages. IMHO
when experiencing problems in a software package most users should first
update their software to the most recent version and if the problems persist
report the problem. Or they should check mailing list archives and release
notes for indications that they are experiencing a known error.
These indications should not be buried in countless pages of detailed
explanations of every crossed t and dotted i in the software, but they
should be based on to the point oneliners for each significant bug that is
fixed or feature that is added.
>
> > All this is not only done in a favor for the one user but also in favor
> > of all the other customers and developers: If Célio can quickly verify
> > whether his SMP problem is related to the bug you fixed or not, he can
> > quicker or better report his problem.
To Mathias: no, if Célio has a problem and wants it fixed, he should report
it. Don't wait until other reports come along that may match your problem.
>
> > * Referring to the revision numbers of the (public) source code
> > repository, even better if the developers follow a descent commit
> > message policy:
> >
> > BUG: Fixed https and client certificates (r4711, r4715)
>
> Could be done. But 99% of all users won't care or understand about the
> sourcecode.
Agreed, but here I think it would be wise to use the same method you
currently use when replying to the dev list (you know, your trademarked
'fixed in revision NNNN' ;)
That would provide the entry point for users interested enough to start
digging for details.
> Ok then. I hope you like books, because that one will be long:
>
> In TSVN, many dialogs use more than just one thread. Most use two
> threads, one responsible for the UI, and one to execute longer tasks
> like fetching the status of a working copy. To synchronize those
> threads, a boolean variable is used to indicate if the worker thread is
> running. If it is running, the UI thread isn't allowed to access data
> which the worker thread is updating. Otherwise a crash can occur due to
> the data not being valid (either because it was already removed,
> replaced or not yet fully added).
> On SMP systems, that variable isn't enough. Some SMP systems also have
> different processor caches. If the worker thread now sets the 'blocking'
> variable, the UI thread running on another processor and using the cache
> of the other processor, that variable isn't always updated in the other
> cache in time. So even if the worker thread indicates that it is working
> on data, the UI thread might not notice it because that processor still
> has the old value of that variable in the cache.
> To avoid such situations, we'd have to use special APIs which force the
> processor caches to be updated (by flushing the modified variable to
> main memory).
> This problem affects almost all of the TSVN dialogs and the cache.
> (now I could write another two pages about the specific situations where
> this could actually happen).
Steve can you elaborate on this ;-)
As you can see, most users won't care about this, and most won't
> understand it either. But I had to sit down and spend 15 minutes writing
> this stuff. 15 minutes I could have spent coding.
But you did put something like this explanation somewhere in the code and/or
log messages did you? Because this information IS relevant, if not for
yourself then at least for the poor soul ;) that has to maintain your code
in 10 years.
> > Simple fixes for diffuse problem situations often don't seem worth the
> > effort for describing what was did and why. The more effort the
> > developer had fixing the issue, the more time he is willing to spend on
> > describing his hard work. Even if from the user's point of view the
> > justification may look quite different. :)
>
> You can do that if you're in a team.
Do keep in mind that every program over 200 lines of code ;) will have areas
that are left alone for long periods of time, and even with one developer,
that piece of code will look like being written by someone else. Without
proper comments and version history available, maintenance will become
harder.
--
Regards,
Jean-Marc
----------------
___
// \\ @@ "De Chelonian Mobile"
/ \_/ \/._) TortoiseSVN
<\_/_\_/ / The coolest Interface to (Sub)Version Control
/_/ \_\ Check out http://tortoisesvn.org
Received on Thu Jan 26 22:16:51 2006