SVNPorxy RC is not ready to laucnh

Thanks, Igor. I really appreciate your work anâ all my comments are aimed
to make your products better so that I can use them in my daily work.
Please, do not stop at what you've done, make it better al the time :)

Here are my additional comments:

3) I think, this not an organizational issue.
Here is the scenario:

a) User #1 and User #2 both have the same solution, all files are
checked in in and the system is up to date. Both users have Delete
Monitoring option on.
b) #1 deletes the file from VS. Project file is checked out (as the file
is removed from project list) and PushOK delete monitoring dialog appears.
#1 clicks ok and the file is deleted immidietly from SVN. Note, that #1
does NOT make checking and project file is still checked out.
c) After point b) user #2 make full update of solution. Note, that since
project has NOT been checked in by #1, project XML is NOT updated and keeps
reference to the deleted file.
d) Right after having made update #2 will get notice from PushOK about
Delete the file which #1 deleted before. Note several things here:
* #2 does not no nothing about what to do as there is no connection
between #1 and #2 at this time.
* Even if #2 tries to cancel delete, file is not there (it's been
removed from SVN repository in current revision).
* So after updating solution the project will keep reference to file,
but the file is not presented in file system
c) when #2 compiles the solution, he gets a compilation error as there is
another file which uses data in deleted file. Since #1 has not checked in
his changes yet, this is a bug.

So I consider such a behaviour as a critical bug which can block user from
team development.

7) I mean, that when you are in VS and click history on the file, you get
history dialog. When you select the revision you want to look at and click
View, external application is started. But this is not good - it's much
better to open history items in the same VS which I opened history dialog
from. This is the way how MS VSS works. When you look at a file history and
click View, it opens file's source in the source VS window. History dialog
has Close button on it if you want to close it and go to source.

Ok, hope this will help.

By the way, I have on more suggestion:

12) In history dialog you have checkboxes. These checkboxes works only for
comparison option. TO make annotation or view thó file, you have to click
in the history record before clicking View or other button. This breaks my
mind some time. I select checkbox (as this usual intention) and click View
button. It opens the file and after that I realize that it opens not the
file I checked but the selected file. I suggest removing checkboxes and use
Ctrl+Selection option. And I also suggest placing buttons on the right side
of the dialog one abovó other, with one fixed width.

Thanks a lot, guys, you do a great job!

I managed to find several error which actually blocks me from using SVN
proxy in my multimember development team. More than that, most of these
problems comes from CVS proxy :

1. There is no way to understand from VS the revision # of the
class/projects.
In the history dialog there is no "Current" label near the revision of my
working copy. In CVS I can see "CURRENT" label which helps me a lot
sometimes.

2. If there are conflicts in file, update always embeddes svn extra info
into file source. Even if option "Launch confilt editor..." is ON. This is
a problem as if the conflict is in project file I have a problem.
More on this. Try to think as VS developer: when you have a conflict, it's
not very easy to resolve it based on extra info embedded into the file
after updating. The way I usually use is to compare my working copy and
head revision with diff editor. This is much easier and error prone than
trying to make it in one file.
I know that if ""Launch confilt editor..." is ON it should NOT change local
file, but show conflict editor. It doesn't, but even if it did, it's not
always good. When I make common update of the solution and I have a lot of
files checked out and there have been a lot of changes in the system after
I checked out my files, I do not want to see 10-20 screens of my conflict
editors. All I want to do is to update my solution and SEE WHICH FILES
REQUIRE CONFLICT RESOLVING. Without any problems with changing my code,
etc. After that, if I have this list of conflict files, I can go one by
one, use compare option with repository and resolve the conflict. I think
there must additional tab in VS to see such conflict files.
But still in any case there have to be NO conflict markers in proj files.

3. Rename/Delete monitoring options can block solution compilation.
When someone delete files from solutions, he sees Delete monitoring dialog.
Surely, he presses OK on it. Note that he doesn't do commit on soluiton.
But pressing OK on Delete monitoring dialog makes commit to repository. And
When another user gets latest version, he will not have this file on the
working copy, while proj file still keeps ref on it. This will couse
compilation problems, as user 1 didn't check in his other changes.
This is actually critical issue for multi developer working and I faced
with this problem 10 times since I understooв the problem.
More on this. This monitoring dialog and very poor UI/usability design
beneath the logical problrms. Why should I press OK twice during commiting
delete? All I need having simple confirmation dialog with simple Ok/Cancel
button. More than that, there is no need to monitor deleting outside the VS
- it just make me med. When I delete the file outside the VS, I will take
care to remove it from VS myself, be sure.
Look at TortoiseSVN how they work with file deleting/renaming. Main idea is
that there have to be no auto commit. When I delete file, I also usually
change my other existing files to remove dependency to the deleted file.
When I have compiled version, I make commit, but not before.

4. History dialog is not really good.
Look at TortoiseSVN how they work with history. I can see deleteting,
renaming and other things on the file.

5. History / project mode doesn't work.
It just doesn't show me latest changes made by other people.

6. No option to update to specific Revision.

7. No way to see file source from the file history in the same VS
application. VSS manage to do it.

8. No way to set up file titles for external file comparers (ususally it
have to be resision number).
Look at TortoiseSVN.

9. No way to work with branches.
I know that branche/tag in SVN is just a file copy. This is not the reason
to remove option to compare this file with another located on different
URL.

10. SLN, PROJ, RESX files have to be processed with great care.
Confilcts and other things have to be procecced with care, not the way it
usually works with code files. For big RESX files it's really difficult to
find conflict markers.

11. History of the file/project have to be redesined in order to give the
developer ability to understand the full history of file's changes. I have
to have option to see what happens on the project in terms of
commit/add/remove plus comments. I think the base idea can be taken from
TortoiseSVN.

Hope to here and answer from you, as I were planning to move my dev team
from CVS to SVN and use SVN proxy. But with all these things I can see no
way to do it. Using CVS proxy with about 10 developers showed a lot of
problmes in daily usage.