Forum Discussion

gdave's avatar
gdave
Regular Contributor
5 years ago

Multiple Node Lock Licenses

Hi all We currently have 2 node locked TC licenses. Only one was in use till date however we now have plans to get additional resource using second license. My issue here is, since I was the sole u...
  • AlexKaras's avatar
    AlexKaras
    5 years ago

    Hi,

     

    Basically, TestComplete does not support concurrent development.
    You may try to open the project in a Shared Mode from the network share. In this case TestComplete will monitor changes made to the project items and suggest you to reload changed entity. Two problems here:

    a) There are no means to either see what was changed or to visually compare/merge your current and remote entity. You can either accept or decline to reload;

    b) TestComplete implements the 'last writer wins' strategy. This means that if you reload the entity you will lose your changes. If you refuse to reload, then you will overwrite changes made by your colleague.

     

    Also note, that only script unit files can be (visually) merged. All other files from TestComplete project are XMLs with complex internal structure and thus can not be merged in practice.

     

    The recommended approach with TestComplete is to split the work so that no collision happen. And if someone needs to add some new entity to the project or update existing shared one (e.g. NameMapping) this must be done in a controllable way to prevent merging.

     

AlexKaras's avatar
AlexKaras
Champion Level 3

Hi,

 

Basically, TestComplete does not support concurrent development.
You may try to open the project in a Shared Mode from the network share. In this case TestComplete will monitor changes made to the project items and suggest you to reload changed entity. Two problems here:

a) There are no means to either see what was changed or to visually compare/merge your current and remote entity. You can either accept or decline to reload;

b) TestComplete implements the 'last writer wins' strategy. This means that if you reload the entity you will lose your changes. If you refuse to reload, then you will overwrite changes made by your colleague.

 

Also note, that only script unit files can be (visually) merged. All other files from TestComplete project are XMLs with complex internal structure and thus can not be merged in practice.

 

The recommended approach with TestComplete is to split the work so that no collision happen. And if someone needs to add some new entity to the project or update existing shared one (e.g. NameMapping) this must be done in a controllable way to prevent merging.

 

gdave's avatar
gdave
Regular Contributor
5 years ago

 

AlexKaras wrote:

Hi,

 

Basically, TestComplete does not support concurrent development.
You may try to open the project in a Shared Mode from the network share. In this case TestComplete will monitor changes made to the project items and suggest you to reload changed entity. Two problems here:

a) There are no means to either see what was changed or to visually compare/merge your current and remote entity. You can either accept or decline to reload;

b) TestComplete uses the 'last writer wins' strategy. This means that if you reload the entity you will lost your changes. If you refuse to reload, then you will overwrite changes made by your colleague.

 

Also note, that only script unit files can be (visually) merged. All other files from TestComplete project are XMLs with complex internal structure and thus can not be merged in practice.

 

The recommended approach with TestComplete is to split the work so that no collision happen. And if someone needs to add some new entity to the project or update existing shared one (e.g. NameMapping) this must be done in a controllable way to prevent merging.

 

Thanks for the detailed explanation.

Do you think source control applications like GIT can also be of help ?

  • Marsha_R's avatar
    Marsha_R
    Moderator
    5 years ago

    You can certainly use a source control application, but there are still some files that should not be shared as AlexKaras described.  Each person should have their own copy of the test suite to work in and then good communication amongst the team is mandatory, even when version control is used.

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    5 years ago

    Hi,

     

    > Do you think source control applications like GIT can also be of help ?

    Not really. Just as a source control (i.e. - storage). As I wrote, merging of all files that TestComplete project consists of is near to impossible. Merging of script source code is possible, but personally I prefer to avoid merging of source code as much as possible as well.

    As Marsha_R already mentioned, your best friend in concurrent development is code decomposition by modules and close team communication.

     

    • Marsha_R's avatar
      Marsha_R
      Moderator
      5 years ago

      I think it works for us because no one works on the same test at the same time.  We are only ever merging with the last copy and not another person's concurrent work.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    5 years ago

    Definitely GIT or Mercurial.

    However, I do disagree with the inability to merge some files.  NameMapping, DEFINITELY, I'd approach with extreme caution using a merge utility.  However, other files can be easily deciphered to merge visually.  But that's the best way to do this... use a source control tool, work in separate branches, and then co-ordinate for merges and such.

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      5 years ago

      gdave :

       

      > other files can be easily deciphered to merge visually.

      Yes, I do agree with Robert that internal structure of TestComplete's project files is not a rocket science. The question is whether or not would you like to do this.

      Open any project file in a Notepad and try to understand its structure to get an idea.

       

    • gdave's avatar
      gdave
      Regular Contributor
      5 years ago
      tristaanogre wrote:

      Definitely GIT or Mercurial.

      However, I do disagree with the inability to merge some files.  NameMapping, DEFINITELY, I'd approach with extreme caution using a merge utility.  However, other files can be easily deciphered to merge visually.  But that's the best way to do this... use a source control tool, work in separate branches, and then co-ordinate for merges and such.

      We’ll certainly take the approach of each user have their own copy of the test and no one will work on the same test at the same time.

      However, we are unable to host main project on our shared drive as it makes TC very slow. This is an organizational infrastructure limitation and we aren’t able to resolve this.

      So as a work around, till date I use to host the main project on my local C: drive (as TC works seamlessly when access via C: drive). A copy of the project was also saved on shared drive as a backup. Once or twice every week I would manually copy the project file from C: drive over to the share drive to create most up to date back up.

      Now the above model worked fine until now (since I was the sole user). However with the introduction of additional user I don’t see this model working. The last user to save the backup file will overwrite the changes made by the other user.

      AlexKaras Marsha_R 

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        5 years ago
        gdave wrote:

        However, we are unable to host main project on our shared drive as it makes TC very slow. This is an organizational infrastructure limitation and we aren’t able to resolve this.

        So as a work around, till date I use to host the main project on my local C: drive (as TC works seamlessly when access via C: drive). A copy of the project was also saved on shared drive as a backup. Once or twice every week I would manually copy the project file from C: drive over to the share drive to create most up to date back up.

        Now the above model worked fine until now (since I was the sole user). However with the introduction of additional user I don’t see this model working. The last user to save the backup file will overwrite the changes made by the other user.

        AlexKaras Marsha_R 

        Hence, source control is the way to go.  GIT or Mercurial are free so you're not buying a new tool.  But definitely, you'll need to implemnet something like this.