Adminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
My feedback
-
9 votes
-
1 vote
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.
-
47 votes
We talked about this feature with Microsoft. There is currently no supported API to support this feature :(
Both the UI and the implementation are part of the TFS package that is part of Visual Studio Ultimate. We hope that there will be an api for it in the next version of Visual Studio.
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.
-
9 votes
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.
-
9 votes
I agree, performing the unlock operation (by pressing Commit) would be a nice thing to do.
Is this version of the comment clearer?
-
4 votes
-
7 votesAdminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
shared this idea
·
-
13 votesAdminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
shared this idea
·
-
9 votes
-
72 votes
The right click —> Use template option will certainly work and fits nicely in the current workflow
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.
-
41 votes
This is on our TODO list. It just needs a good design to work correctly (especially around VS crashes)
Adminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
supported this idea
·
-
3 votes
Note that it is possible to leave the project name empty in the ‘add to subversion’ dialogs. This makes the entire path/url user editable.
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).
-
3 votes
I would love to have this feature in AnkhSVN, but it looks like it will be very hard to implement this for AnkhSVN specifically.
The good news is that one of the subversion developers said that he is going to add support for it for Subversion 1.8, which should automatically enable us to use this feature.
Subversion 1.7 will have better patch support than the current version which might help us add some intermediate support.
Adminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
supported this idea
·
-
9 votes
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.
-
302 votes
@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!
Adminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
shared this idea
·
-
303 votes
I will start inviting translators around September 2011. (I hope to have a dummy translation ready by then) Please contact us via the mailinglist if you like to help.
[Updated to follow reality. Rescheduling now as Subversion 1.7 is on its way]
Adminrhuijben
(Bert Huijben, AnkhSVN & SharpSvn Projects)
shared this idea
·
-
9 votes
With the current working copy format most time is spend in waiting for the disk and not with the actual updating. Tests showed that doing this synchronously doesn’t really help. Maybe when subversion is switched to WC-NG.
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.
-
1 vote
It should be possible to implement a MSSCCI provider using .Net 4.0 as that can work side by side in .Net 1.X applications.
This would allow some level of code reuse. (But none of the current AnkhSVN developers is personally interested in this feature at this time)
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.
-
139 votes
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?
Any particular file and/or project type where this happens (more often)?