Forum Discussion

sv_sarma's avatar
sv_sarma
Occasional Contributor
10 years ago
Solved

Multiple Checkout/Checkins from TestComplete with SVN Integration

Hi,

We have integrated Collabnet SVN with our TestComplete code. I just wanted to know if we can have multiple checkins/checkouts on the Poject Suite so that one or more test engineers can work on the same code. Welcome any suggestions on achieving this at the Project Suite or Project Level.



Thanks,

Sarma Kasibhatla
  • AlexKaras's avatar
    AlexKaras
    10 years ago
    Hi Sarma,



    Files that compose TestComplete's project and project suite are described here: http://support.smartbear.com/viewarticle/56608/.

    Generally speaking, the structure of the project is quite logical and you should be able to figure-out what files are expected to be changed when you change this or that in the project.

    For example, if you add a new script unit to the project, script file and Script.tcScript file are expected to be changed. If you change some project setting, you should expect changes in the corresponding .mds file, etc.

    The problem here, as I have said, is that those files are near to impossible to be merged even manually, so the only approach that will work with concurrent development is:

    -- Think beforehand what you are going to change and what files this will influence;

    -- Check-out and lock required files;

    -- Make changes;

    -- Check-in and unlock changed files.



    Obviously, no one will be able to use this scheme in the real life during development.

    I would suggest you to make an experiment: make two copies of the same project in separate folders; make different changes to them from TestComplete (or even logically the same ones, for example, add new project variable of the same name, type, etc.) and then try to compare the changes and consider: a) whether those changes can be correctly merged automatically; and b) how easy will be to correctly merge those changes manually. After this experiment you may re-consider my suggestion about dedicated person who makes manual merge in TestComplete's IDE and then submits changed test suite into the source code control system.

5 Replies

Sort By
  • chrisb's avatar
    chrisb
    Regular Contributor
    10 years ago
    We are doing concurrent test development with source integration with relatively few problems. The biggest issue we came across was adding new scripts. In this scenario TC automatically checks out and updates the script.tcscript file. This needs to be checked back in immediately after the script file has been checked in. If we don't do this then other users get warning messages that the script file that TC expects to be in the project is not available.



    To work around this we get the user who adds a new script to check the blank script file in immediately after creation and then check it back out and keep it checked out for the time they are working on it. This is a bit of a quirky workflow but it works. 



    After experimenting with different source control workflows I came to the conclusion that concurrent test development using source control is not well supported by Test Complete and something you really have to experiment with using your source control tools to find what works for you. Also we are not using namemapping  in the project which I suspect this reduces the complexity of the files types that could need to be merged.



    With regards to merging I've only seen a couple of occasions where there was an issue merging and Vault was able to resolve that itself automatically.





    If you were wondering, we are using SourceGear Vault product with a VSS Style workflow - Check Out / Edit / Check In.
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    10 years ago
    Hi Sarma,



    a) I believe that you already went through the http://support.smartbear.com/viewarticle/57266/ help topic;

    b) In general, concurrent development is not recommended with TestComplete. The best approach is to have test engineers working on their totally independent areas and to have one responsible person who will merge changes made to the common shared code and check-in modified project as a whole. While this may sound as an approach that you did not expect for, this is the most reliable approach. The reason for it is that all TestComplete project files (except script units, which are plain text files) have internal references based on auto-generated unique identifiers that are near to impossible merge (either automatically or manually).



    Try to search more this forum - there were several similair discussions here ended with the same result.
  • sv_sarma's avatar
    sv_sarma
    Occasional Contributor
    10 years ago
    Thank you Alex, I am not sure if we can have SVN solution for our Problem. 

    We are exploring another solution with Accurev, where we would like to create a workspace and upload the entire Project Suite.

    Is it possible to identify what files will be changed when we make changes to name mappings, script tests, keyword tests and etc? so that we will maintain these files in the SCM tool and remaining files/folders as static items. Is there any reference of these files in any of the TestComplete documents? 



    Thanks,

    Sarma K
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    10 years ago
    Hi Sarma,



    Files that compose TestComplete's project and project suite are described here: http://support.smartbear.com/viewarticle/56608/.

    Generally speaking, the structure of the project is quite logical and you should be able to figure-out what files are expected to be changed when you change this or that in the project.

    For example, if you add a new script unit to the project, script file and Script.tcScript file are expected to be changed. If you change some project setting, you should expect changes in the corresponding .mds file, etc.

    The problem here, as I have said, is that those files are near to impossible to be merged even manually, so the only approach that will work with concurrent development is:

    -- Think beforehand what you are going to change and what files this will influence;

    -- Check-out and lock required files;

    -- Make changes;

    -- Check-in and unlock changed files.



    Obviously, no one will be able to use this scheme in the real life during development.

    I would suggest you to make an experiment: make two copies of the same project in separate folders; make different changes to them from TestComplete (or even logically the same ones, for example, add new project variable of the same name, type, etc.) and then try to compare the changes and consider: a) whether those changes can be correctly merged automatically; and b) how easy will be to correctly merge those changes manually. After this experiment you may re-consider my suggestion about dedicated person who makes manual merge in TestComplete's IDE and then submits changed test suite into the source code control system.
  • sv_sarma's avatar
    sv_sarma
    Occasional Contributor
    10 years ago
    Thanks Alex! We will try the options.



    Thanks,

    Sarma K