Hello all,
I am a PB (12.5.2) developer and I have written many apps with this powerful tool for many years.
I work for a small software company and I've been the only PB developer for a long time.
In the last years my team has grown and now we're five people.
We also have web (PHP) projects and we've been always using SVN (with Tortoise Client) for them.
We have a company NAS running a small Linux distro with SVN (1.7) installed on it and we developers (all remote workers) connect to it via VPN and are happy with it. With PHP apps we never used a lock-modify-unlock versioning model; we always preferred a copy-modify-merge solution which is the best if there's two or more people working on the same app at the same time.
We've never used a SCC tool for PB apps in the past, but now that we're five we urge to start with such a tool. Since we have a SVN server already set up and running, we've chosen to interface PB with SVN.
We have about 10 PB applications and a Class Library developed by us; applications have dependencies one upon the other and our folder structure is the following (+=folder, -=file):
c:\pbapps
+ app1
- app1_feature1.pbl
- app1_feature2.pbl
- ..
+ app2
- app2_feature1.pbl
- ...
+ appN
...
+ lib
- lib1.pbl
- lib2.pbl
The total number of PBLs is nearly 800, with about 10 objects per PBL: so we've about 8,000 objects.
We've tried to put the PBLs as a whole into SVN and manage them all via Tortoise and ProDiff.
Of course we failed, since when one of us performs a simple full rebuild of an app PB changes all the PBLs (also the ones of other apps but used by the current one, i.e. belonging to its Library List), and then Tortoise will try to commit all of them, possibily overwriting "real" changes made by other developers.
So, we diligently opened the PB User Guide, Chapter 3, and we:
- downloaded and installed PushOK SVN SCC module;
- "folderized" our PBLs (one PBL per folder - what a pain to adjust all the references to external resources!)
- put one of the apps (the one with less dependencies, about 100 PBLs in total) under version control and started to test.
After a couple of weeks we found these issues:
- PB takes ages (= hours) to import a target into SVN. Actually, PB gets slower in many standard operations.
- PB does version control on objects, not on PBLs. So you can't simply checkout your repo from PB and start working: you have to download the PBLs from somewhere (we put them manually into a subfolder and add it to SVN via Tortoise), sync them with a GLV and then start working. And, any time you modify an object, the PBLs get out of sync. And, if you add a new PBL, you have to put it manually in the folder. What a pain (no. 2).
- PB does not manage other files (.ini, .png, etc) so we have to manage them manually with Tortoise.
- PB requires a developer to lock a PBL before she can work on it. This means no copy-modify-merge model.
- If a developer has no internet connection he can't check out and so he can't work. He has to copy the local PBLs in another folder (out of version control), track someway the changes he makes and then import them manually into version control when he can get on the internet. What a pain (no. 3).
- Normal operations such as moving an object from a PBL to another become nightmares. PB crashes frequently and PBG files can get damaged (we have no experience of the latter but I read many PB devs having such issues).
Are these "real" problems or are we making some mistakes in managing the PB-SVN link?
Can you give me some suggestions and/or point me to whatever online material which describes the best practices to manage shared source-controlled projects in PB?
Thank you a lot!
Luca
P.S. Armeen, if you're listening... We REALLY NEED to get rid of PBLs ;-)