3 votesTobias supported this idea ·Tobias shared this idea ·
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.Tobias commented
Add to subversion
-> Sorry, my fault, I thought that the project name cannot be empty.
That was all I wanted from ankh.
Our SLN is not checked in and this is fine:
One SLN for all developers has some major drawbacks for us:
Assume you have a couple of own company assembly's.
- employee A is responsible for assembly A
- All other employees should use in their Projects a well known version of assembly A.
. If there is a bug in Assembly A, Employee A should fix it, therefore he should be able to debug the Assembly A while executing App using it.
- All project references to assembly's are relative to the project file, because we won't force developers to have a certain directory structure, nor installed any third party SDK's.
- Some own Assembly's rely on others, some not.
The best way we found is local references to Assembly's located within the a lib dir in the project dir. For debugging, only one developer can set the reference to another DLL project within his own SLN. ( But he must take care not to check in this reference, when debugging is done, the reference must be set back to the binary Assembly file located in the lib dir.)
To enforce up to date DLL's in the lib dir, we have custom scripts as post-build commands. ( They check the %USERNAME% and copy as needed for each developer's project structure)
To put it all into a nutshell:
It works as it is with ankh, but could be a bit better. I know that we are using a uncommon approach so Visual Studio itself is drawback, ankh is just fine as it is.