Using subversion in PDSOE - Forum - OpenEdge Development - Progress Community
 Forum

Using subversion in PDSOE

This question is not answered

Dear All,

When you want to share a project to subversion repository what need to be shared?

The whole project or only the source files of the project.

Are there items within a project you should not share?

Kind regards,

Peter Wokke

All Replies
  • Peter, That is really a question of semantics. You should put those file into your SVN repo that you wish to have version control over. All of your source code is a good start. Any control files your application requires should also be stored. If you plan on doing any Continuous Integration / Delivery, then all files that are required to build and run your application should be stored in the a repository. You do not have to store everything in the same place, nor does it have to be in the same projects but it should be stored somewhere.

    If you have multiple developers working on the same project I would recommend you NOT store the .project .dbconnections files. These files are developer specific for PDSOE.

    When using Subclipse in PDSOE, there are some files that are automatically not included (Eclipse control files). This can be a good thing or bad depending on your application.

    Regard, Cameron

  • Hi Cameron,
     
    I disagree on your view on .project and .dbconnection.
     
    .project gives the project it’s name.
    .dbconnection just names a logical DB profile
    .propath is the PROPATH – and in multi-project setups the propath references other projects by the name (.project file).
     
    None of this is developer specific. But all of this is relevant project configuration that may require versioning (if it changes over time).
     
    What may be developer specific are the actual connection parameters or the physical location of the projects. But those are not stored in any of those files.
     
    You should also export the project startup parameters etc. (project properties, OpenEdge, Share settings). This produces the project.xml file.
     
    So, we store the .project, .dbconnection, .propath and project.xml in the SCM tool (Perforce for us) and that helps us restoring even complex workspaces in a few minutes from SCM.
     
    Cheers,
    Mike
    Von: cwright [mailto:bounce-cwright@community.progress.com]
    Gesendet: Montag, 24.
    Oktober 2016 14:01
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] Using subversion in PDSOE
     
    /cfs-file/__key/communityserver-discussions-components-files/19/7762.image001.png
    Update from Progress Community
    /cfs-file/__key/communityserver-discussions-components-files/19/7762.image002.jpg
     

    Peter, That is really a question of semantics. You should put those file into your SVN repo that you wish to have version control over. All of your source code is a good start. Any control files your application requires should also be stored. If you plan on doing any Continuous Integration / Delivery, then all files that are required to build and run your application should be stored in the a repository. You do not have to store everything in the same place, nor does it have to be in the same projects but it should be stored somewhere.

    If you have multiple developers working on the same project I would recommend you NOT store the .project .dbconnections files. These files are developer specific for PDSOE.

    When using Subclipse in PDSOE, there are some files that are automatically not included (Eclipse control files). This can be a good thing or bad depending on your application.

    Regard, Cameron

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    https://community.progress.com/notification/read?NotificationId=6ba75561-40dd-4c2f-aaa1-ad1203dfa700
     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Mike,

      Your point is noted. However, if I share .project, then it forces all developers to use the exact same project name. It also forces all developers to have the same natures and facets (they are stored in .project). Same with .dbconnections. This forces all developer to have the same local names and directory structure for their database connections. If you have local dbs, this can cause issues. There are advantages and disadvantages to storing the .project and .dbconnections. You have to weight them for your environment.

    I think it is wise to export your setting and make that export available to developers in the event they need to restore, but forcing everyone to have the same names and directory structure is a bit rigid for my development style.

    I do agree with .propath. That should always be the same or you can cause a massive mess during downstream builds

    Cameron

  • We store source only, none of the project settings, but we are very small, not many developers and we let them manage the environments.  

    Another factor, is that we support multiple versions of OE (10.2B and 11.6)  This has caused some source control challenges.  The source itself has pre-processors to handle the code parts, so we do not have separate trunks by OE version.  However, the .assemblies varies between OE version, so that is an example of a file that is not versioned in source control.  

    We do store .resx and .wrx, in source control, but recently found we have .resx problems if a UI is modified in 11.6 then built with 10.2B.  No compile errors, but at runtime, you have some problems loading the .resx data.  For this reason, we have an informal rule to only modify UI with 10.2B, not 11.6.  There might be a better way to handle this?

  • We have written unit tests that verify that Resx files work on every target release of OE. 10.2B and 11.3-11.6 for us.


    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.