Using subversion in PDSOE

Posted by PeterWokke on 24-Oct-2016 05:46

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

Posted by cwright on 24-Oct-2016 06:59

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

Posted by Mike Fechner on 24-Oct-2016 07:14

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
 

Posted by cwright on 24-Oct-2016 07:30

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

Posted by Steve Croff on 24-Oct-2016 10:04

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?

Posted by Mike Fechner on 24-Oct-2016 12:49

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.


This thread is closed