>I have been toying with a similar idea for some time, and I'm not sure
>it's feasible to do.
> - This system would be file-centric. That is, you would be leaving
> comments on individual files. This *mostly* maps pretty bad with reality
> as files are far too granular in many cases.
This might be true for some of the cases. Nevertheless, some types of
benefit from it. (Like reviewing single images or code files)
Another option would be setting the properties for directories.
>- There will be problems when many people wants to leave a comment at
>the same time. (So the "tsvn:comment_N"-idea would not work.) Somehow
>handling or merging of these cases must be solved.
Very true. I was thinking about the same thing. I'm not quite sure how
does the svn handle conflicts on properties? Aren't they somehow the
same as regular files. If so, then the
format of the comments should be mergeable and on conflict, the
comment UI should provide an intelligent way to resolve the situation.
That is, it needs to understand the format of the comment property,
which it needs to do anyway.
I understand that there are problems with this kind of special cases:
it is better to have a system (subversion client library) that is used
every time the same way.
>- We would need to find a way to make the comments easily "visible".
>Having to use the property dialog to find out if there are any potential
>comments is way too complicated. This could prove difficult to fit in
>TSVN, where it is an integral part of (almost) any issue-tracker
Maybe I didn't express my idea clearly enough. I visioned that at
first phase, there would be
a new tool (having an UI more or less similar to TortoiseMerge) which
shows the comments on the source code (or image). At later phase, we
could lure the authors of various editors (namely emacs, vi, ultra
edit, etc.) into incorporating subversion and tsvn:comment support
into their IDE's. This way, the comments would be always visible on
the editor when needed.
>Bottom line: It sounds like a cool technical thing to do, but isn't an
>issue tracker what you /really/ would want instead?
Yeah, it could be. But there might be also some uses of this technique
we cannot even imagine yet. I agree that this needs more thoughts
before any implementation or design attempts.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 16 15:19:18 2006