I suggest you ...

support complexer directory structures

We need complexer directory structures within the repository.
Especially the need of *custom* subdirs (not to be forced to use the project name as subdir)

We want to use Ankh to add an existing Project
to a complete custom path to the repository.

Example: Our project is named ProjectA
and we want a repository structure like this:

/root/container/projectA/doc/trunk
/root/container/projectA/scr/trunk

and so on for depending projects...

Currently I cannot use Ankh to add an existing Project to
/root/container/projectA/scr/trunk !
To do this is not trivial at the moment and I can't see a good reason for that!

Please add this little bit of code to ankh, It should not be that hard..

3 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    TobiasTobias shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • TobiasTobias commented  ·   ·  Flag as inappropriate

        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.

      • rhuijbenAdminrhuijben (Bert Huijben, AnkhSVN & SharpSvn Projects) commented  ·   ·  Flag as inappropriate

        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)

      • rhuijbenAdminrhuijben (Bert Huijben, AnkhSVN & SharpSvn Projects) commented  ·   ·  Flag as inappropriate

        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).

      • TobiasTobias commented  ·   ·  Flag as inappropriate

        In this scenario the solution selves should not stand under version control!

        => the projects within one SLN are located in very different repo-dirs!

        ( In fact, every user should build his own SLN, depending on what Module he is responsible for .
        For other Modules (Assemblies he is not responsible for), he can add a reference to a binary version, exported once from repository) )

      Feedback and Knowledge Base