Zeus IDE

For the past 30 years we have been using M:\ as the folder to contain our projects. M: itself has always been mapped (either with SUBST or NET USE) to the actual location where the files currently being used were located. This made it easy for all projects to use the same path settings, etc. Our old source control provides had no problem with this and neither did (or does) Visual Studio (or any of its precursors.)

I'm trying to open our project from source control using AgentSVN via the 'Open from source control' menu option, but I am not allowed to choose the root. That means I am simple not allowed to open our solution from source control because it is (and always has been) in the root.

Is there any way around the seemingly arbitrary restriction? We are not going to attempt to change 30 years of history just to accommodate a new tool.

Oh, FWIW, if I just open the solution in Visual Studio 2022, it shows the source control binding but for some reason says that it is not connected and provides not way to get connected that I can find. That also seems like it may be a bug in AgentSVN, because it is my belief that as the SCCP AgentSVN should be establishing the connection when our projects are loaded.

Yes, I've only been working with AgentSVN for several hours, but I keep hitting issues with documentation that make me wonder if anyone has updated it in the past several years. For example, the TortoiseSVN documentation explains how to use the SVN Checkout and SVN Checkin functions that were added to the File Explorer context menu, but those don't exist and current versions of SVN don't support checkin/checkout commands. I've encountered similar things with all the SVN and SVN-related documentation I've been reading through. That's why I'm hoping people who actually maintain and/or use this stuff can (and will) help.

Thanks

The reason for this restriction is because the root folder maps to the root of the Subversion tree. If Agent SVN bound to that location, it would mean there would only ever be one project in that Subversion tree, which is obviously wrong.

Now if your Subversion tree is structured in this way then you can do the following:

1. Use TortoiseSVN to checkout that root folder to the local machine, which will create a Subversion local working copy.
2. Inside that local working copy folder, open the solution file using Visual Studio.
3. Use the Visual Studio File, Source Control, Change Source Control menu and use the bind options to bind to that local working copy to the project and solution.

Now that project will be bound to the Subversion local working copy, and that local working copy is connected Subversion tree via the earlier checkout.
Out of interest I searched the Agent SVN help for TortoiseSVN to see if it was mentioned and to see if those mentions in the documentation were wrong.

These were the references found: Both of those references are correct.
What issues do you keep running into with the documentation

In order to offer help, just provide specific details as to which parts of the document you think are incorrect.

Jussi

Here's an example of AgentSVN documentation that doesn't match what I see --
https://www.zeusedit.com/agent/ide/vs/vs2008.html -- it mostly matches as far as I could go, but extra dialogs appear that are not mentioned and by Step 4 the who procedure is kinda off the rails because VS2022 or AgentSVN is doing things for me (without asking) before I even get to the part of Step 4 where I am supposed to do those things myself.

For example, when I opened a solution containing several projects that had NO SOURCE CONTROL bindings (I had previously opened it with source control configured to None and had VS2022 permanently remove all source control bindings.) the solution (project?) was automatically added to source control. Unfortunately, not ALL of the projects in the solution were added, but from that point onward, I was unable to follow the tutorial.
------
Right at the beginning of your reply you said

Use TortoiseSVN to checkout that root folder to the local machine,

which is an interesting thing to say since part of the message you are responding to explains that TortoiseSVN has no such thing as Checkout (or Checkin). The closest I've seen is "Check for modifications..." which is absolutely not the same.
------
Unfortunately, it appears that AgentSVN is attempting to be "too smart" for us to use. We use the mapped drive because there are far, far more things in source control than simply Visual Studio projects. Those things are in separate folders found in the root of the mapped drive (which is also where the primary VS2022 solution file is located). The solution references projects that are each in their own folder located within M:\Source. Our old (32 bit) MSSCC provider didn't care as long as its view of the folder/file locations matched the working copies. It also kept a separate reference copy of everything that was VERY handy for many reasons.
------
Someone tried to help by pointing me at the tutorial (in viewtopic.php?p=13644#p13644) and I'm waiting to see if any additional tips are forthcoming. Sadly, at the moment it does not look like AgentSVN will work for us because it seems to be imposing rules that are incompatible with our system. Assuming we would get it to work at all. For reference, it too about 15 minutes to get VisualSVN working with the same projects, but it doesn't really have any locking checkout/checkin support, at least nothing that can be globally applied (and we weren't going to set needs-lock on every file individually!)
------
Finally, I've been evaluating 64 version control options to replace the home-grown 64<->32 bit MSSCCI component I created to map VS2022's 64 MSSCCI to our old 32 bit MSSCCI provider. Mine appear to work OK, but I don't have a deep understanding of the inconsistently documented MSSCCI interface (for example, the online documentation doesn't match the documentation found in the interface header, scc.h) and I was hoping to find something with locking checkout/checkin that was professionally created and maintained. We're just not ready to trust nuclear power plants, flight control systems, and things like that to source control system that "magically merge changes from multiple users."

Sadly, at the moment it does not look like AgentSVN will work for us because it seems to be imposing rules that are incompatible with our system.

Hence the reason Agent SVN is offered as shareware. You get a 45 day, fully functionally free trial to figure out if the software works for you.

We're just not ready to trust nuclear power plants, flight control systems, and things like that to source control system that "magically merge changes from multiple users."

Hence why the Agent SVN license agreement states the following:
As outlined in that license agreement, the Agent SVN software is not licensed to perform in nuclear power plants or flight control systems. The Agent SVN software is not recommended for use in these kinds of environments as there is absolutely zero guarantee offered or implied the software will perform in such environments.

As to the point of "magically merge changes from multiple users", Agent SVN implements the MS-SCCI and that interface does not define any merge functionality. So once again it would be nice if you could clarify what are these "magical merge issue" that you are seeing.

Cheers Jussi.

which is an interesting thing to say since part of the message you are responding to explains that TortoiseSVN has no such thing as Checkout (or Checkin).

Here is the TortoiseSVN menu used to do checkouts: The checkout can also be done from the command line using the Subversion client: https://svnbook.red-bean.com/en/1.8/svn ... ckout.html

Unfortunately, it appears that AgentSVN is attempting to be "too smart"

All Agent SVN does is connect an IDE to Subversion using MS-SCCI.

Naturally, Subversion has no idea about MS-SCCI as it only understands working copies and Subversion URLs.

How it works is Agent SVN talks to the IDE via MS-SCCI and on the other side Agent SVN talks to Subversion server using the Subversion client.

So rather than Agent SVN being "too smart", it is in fact total dumb when it comes to Subversion. It relies 100% on the Subversion client to talk to the Subversion server.

All Agent SVN does is make sure there is Subversion local working copy available, as that is required by the Subversion client. It also keeps a link between the project name to a Subversion URL which are the referred to as the binding details.

The Binding to an Existing Subversion Project section of the help file describes how these binding details are constructed and how they are effectively nothing more than a Subversion URL.

There is nothing more to it than that.

Jussi