Jarmo Torvinen wrote:
>> - 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
Subversion doesn't merge properties at all. If they differ, Subversion
will always generate a conflict on update.
> 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.
TSVN can't interfere with how Subversion handles properties. We can only
add features to them, but not interfere with them (e.g. during update to
automatically merge them).
>> - 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
Most users have their own editor to edit the files. How would TSVN know
when one of the files is opened with another application and pop up the
And if we provide our own file-viewer together with the comments, that's
not very helpful because users want the tools they're used to.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Oct 16 19:36:51 2006