Any particular file and/or project type where this happens (more often)?

It would be more helpful if you report this kind of problems with some reproduction recipe, to the standard error e-mail adress.

That way you would have found out that you have found a corner case issue in the Subversion core libraries instead of just annoying the developer(s) that you want to resolve your issue.

AnkhSVN internally just calls the backing implementation of 'svn diff' to provide you patch files, and if you tried long enough you would have been able to reproduce this issue yourself. (Which would have required copying some directories, deleting nodes in it, etc. which you didn't mention in your minimalistic report)

A good bug report would have been easy to bump/forward up to the Subversion project, as we can't resolve problems like this in just AnkhSVN or SharpSvn.

With all the missing information and after a few tests I'm guessing that the problem is already fixed since Subversion 1.8.5 which had some relevant fixes. Upgrading to the most recent AnkhSVN would then resolve your problem.

Yes, Git support for codelens provided by the same TFS support that provides the initial codelens support. (Most of Microsoft's Git support goes through their TFS support libraries)

Extending codelens is not supported by Microsoft yet.. Once it will be a supported api we will add support for it.

Any idea which kind of documents were open within reach of the commit?

We just ask Visual Studio to perform a Save operation on the documents that are open within the commit. This message is the result of a document that says it can't be saved.

So whatever we would commit here might not be what you expect, as the document reports that it has in-memory changes that can't be saved.

Is this version of the comment clearer?

The only template currently supported is righ click->"Paste Filename list"

Most other tools only open the commit dialog on an explicit commit and generate a log message at that point. The AnkhSVN pending changes window, however is already open when you didn't change a file yet.

Applying the log message templates as used by other tools would have to be done when you start writing the log message. But there is no event at that point (as the window is potentially always open).

We could at least extend the current 'paste filenames' feature to provide the list via the template instead of just the files.

Having a good solution file for all users makes it much easier to checkout the solution any time you need it. Even if it is just for building..

AnkhSVN supports almost every solution layout as long as the whole solution is in a (preferably one) working copy. Externals are handled fine, but Subversion supports only atomic commits within a single working copy.

If you use multiple working copies in separate places, current AnkhSVN can't check the solution out at once, but most solution level commands should work well over multiple separate workingcopies. (Even pending changes works just fine).

The checkout part is on our todo/issue list. (Technical name: enlist support)

In the 'Add to Subversion' dialog you can leave fields like 'Project Name' empty to allow your own names on all levels.

Visual studio stores project references in the individual project files so your idea of multiple sln files for different references doesn't work.

Besides that, even if you want multiple sln files you can just add all of them to version control to track your changes to them. (Without the .sln you can never have a 100% reproducable build environment).

Your commit will always be against HEAD/Latests and not to BASE, so the solution would be to 'Update' a bit more often. This makes your base equal to Latest and keeps the compare command a local only operation.

@Apolo sun. Were the original checkouts created with the current AnkhSVN release or with an older AnkhSVN/TortoiseSVN.

Some early Subversion 1.6 releases sometimes make a folder 'sparse'. That way updating folders doesn't retrieve new files.

If you have more details that can help us resolve this issue for you please mail our user mailinglist.

Thanks!

Hi,

Could you send us some details on how your working copy is laid out on disk? I'm most interested in whether you use externals below a single working copy root or use multiple separate roots.

We are working on enhancing the experience for multiple separate roots, but completing this task will take some time. If the projects are below a single root it should work and this would be a bug.

Currently implementing an MSSCCI library doesn't fit in our plans. Building an MSSCCI client requires building an CheckOut-CheckIn UI based subversion client in an unmanaged language. While AnkhSVN 2.0 is 100% C# and build on a custom GUI that is tightly integrated in Visual Studio.

Until .Net 4.0 makes it possible to host a .Net environment of choise in any process it requires a full rewrite.

How would you envision 'visually showing that a project is an external reference'.?

For the solution explorer VS has an absolute maximum of 14 glyphs that are availabe in the solution explorer. (All of those in used by AnkhSVN), so we would have to drop another glyph to support an unchanged external project.. then drop another one to draw a changed external project, etc.

Suggestions welcome?