tag:blogger.com,1999:blog-2428374771421713311.post1088066699958354371..comments2024-03-10T12:04:17.661-07:00Comments on The Oracle at Delphi: Parallel or Serial...Anonymoushttp://www.blogger.com/profile/10119008505905401707noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-2428374771421713311.post-36320236584844192802007-07-22T14:07:16.000-07:002007-07-22T14:07:16.000-07:00So Allen, have you you been driven nuts by the amo...So Allen, have you you been driven nuts by the amount of "explicitwidth/height" litter Delphi leaves in otherwise unchanged .dfm files yet? <br><br><br>I hope you guys consider putting in an option to disable these properties.Jacobnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-51522085282017086162007-05-01T03:53:18.000-07:002007-05-01T03:53:18.000-07:00Hello.There is a very nice, open source visual dif...Hello.<br><br><br>There is a very nice, open source visual diff program for Windows: http://winmerge.org/Cd-MaNhttp://hype-free.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-39538312921858524642007-05-01T06:14:31.000-07:002007-05-01T06:14:31.000-07:00We used VSS briefly where I am now. We used it ex...We used VSS briefly where I am now. We used it extensively where I used to work. VSS was great in its day, but MS basically bought it and did nothing with it. We used the serial method when using VSS.<br><br><br>We started using SVN/TortiseSVN over a year ago and now use the parallel model. I was used to the serial approach and had concerns about the parallel approach, but I am totally sold on the parallel approach now.<br><br><br>We have every source file needed to create our product including 3rd party Components in SVN now. The only source that is not in SVN is the VCL source--which we rarely modify--but have on CD if we need to reinstall from scratch. We have our Delphi source, MSVS Source, Installer (Inno) Source, Final Builder Source, Documentation Files, etc. all in SVN.<br><br><br>Our build process is integrated with SVN in that it automatically checks out the HEAD from SVN, builds the files, and then updates the SVN database with the version info that was used to create that build. This way we can easily revert to the entire source used to create any revision.<br><br><br>Where I was before, we had large VSS databases and they would get corrupted frequently. Unfortunatlye, We have had corruption in our SVN database as well.<br><br><br>The main thing that I wish was different about SVN is that uses a file based proprietary database (just like VSS does). If SVN used a real SQL server like MS SQL or InterBase as the database, it would be perfect.<br><br>David R. Robinsonnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-5247293060526868872007-05-01T16:35:45.000-07:002007-05-01T16:35:45.000-07:00We use Sourcegear Vault in "parallel mode&quo...We use Sourcegear Vault in "parallel mode" integrated with bugtracking system Sourcegear Dragnet. <br><br><br>1. Reliable<br><br>2. Remote access. Server side is exposed through web services.<br><br>3. User friendly easy to understand user interface.<br><br>4. Concurrent development style / Parallel development / Atomic checkin transactions.<br><br>5. Affordable.<br><br><br>/MickeMikael Erikssonnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-83418806265021502642007-05-07T15:36:01.000-07:002007-05-07T15:36:01.000-07:00C JohnsonSee http://www.stevetrefethen.com/blog/Co...C Johnson<br><br><br>See http://www.stevetrefethen.com/blog/CommentView,guid,f76b725e-2d01-4655-9514-711656a75022.aspx<br><br><br>I asked the exactly same question to Steve and he answered. In few words, the reasons:<br><br>1) Atomic checkins support<br><br>2) Less maintenance<br><br>Fabricio Araujonoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-28258567402406262732007-04-30T10:03:06.000-07:002007-04-30T10:03:06.000-07:00We use SourceGear Vault. We were previously using ...We use SourceGear Vault. We were previously using SourceSafe, but basically we didn't trust it.<br><br><br>We chose Vault because it had good distributed support (our repository is on a server in Japan, we have developers in New Zealand!), atomic check-ins, and a very similar UI to SourceSafe, which we were familiar with.<br><br><br>We also considered StarTeam and Subversion. Frankly the UI on StarTeam left a lot to be desired, and Subversion missed out because we were happy with the SourceSafe based UI which we were already familiar with.<br><br><br>We use a lock-modify-checkin approach, but we do use the non-exclusive locking, so I would consider it a hybrid serial/parallel approach. We use Araxis Merge for diff/merge.<br><br>Alistair Wardnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-52755145909094186702007-04-30T10:33:23.000-07:002007-04-30T10:33:23.000-07:00We use JEDI VCS to develop JEDI VCS and it does su...We use JEDI VCS to develop JEDI VCS and it does support only the Serial model so far.<br><br>Currently the Serial model is no problem for us, but however we've planned to support the Parallel model in the future.<br><br><br>I personally don't prefer the Serial or the Parallel model, but I have to say something additional to your advise regarding the diff/merge tools.<br><br>If I haven't missed anything then all these tools treat the files as text and that can be a little problem in my POV because for example .dfm files represent objects and should be ideally treated as objects.<br><br>Furthermore form files consist of at least two files (.pas/.dfm) which has to be in sync. I don't think that the diff/merge tools can asure this because they don't know about this relationship.<br><br>Everything gets more and more complicated if you use form inheritence...<br><br><br>BTW, thanks Allen for the Open Tools API.<br><br>For the 3rd party source control integration it would be very nice to resolve QC 44457 (QC 37904).Uwe Schusterhttp://www.delphi-jedi.orgnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-16035527433470324132007-04-30T10:49:24.000-07:002007-04-30T10:49:24.000-07:00I would be more interested in hearing why the DTG ...I would be more interested in hearing why the DTG group dropped or passed over StarTeam - I can't imagine upper management was very happy about it.<br><br><br>C Johnsonnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-714104469979920182007-04-30T13:03:01.000-07:002007-04-30T13:03:01.000-07:00We use Subversion (and TortoiseSVN, of course). Pr...We use Subversion (and TortoiseSVN, of course). Prior to that we used VSS, but we were fed up with how often it corrupted our repository, and with having the entire team idle for most of a day while it was repairing the repository.<br><br><br>We looked at several different source-control systems, but Subversion won out. Atomic commits were a *big* reason for that; I was really pushing for that feature. It's surprising how few revision-control systems have atomic-commit support (Vault was the only other one we looked at that supports it). The repository-wide versions, cheap branching, and price tag (or lack thereof) were also important factors.<br><br><br>The transition to a "parallel" model was far smoother than I had expected. There was a learning curve for all of us, of course, but now I can't even imagine doing a lot of the things we do with a "check out each file" model. We can do big refactorings that would have been a real pain with VSS.Joe Whitehttp://www.excastle.com/blog/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-9898123089872241222007-04-30T13:28:15.000-07:002007-04-30T13:28:15.000-07:00Our team uses VSS but we are evaluating Subversion...Our team uses VSS but we are evaluating Subversion now. <br><br><br>I personally use Araxis Merge - I don't know how any developer could function without an application like that.<br><br><br>I vastly prefer the parallel model - I could never do the major refactorings I do without it.David Robbnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-4800021928688896452007-04-30T14:03:29.000-07:002007-04-30T14:03:29.000-07:00I sorta dragged our whole team from SourceSafe ove...I sorta dragged our whole team from SourceSafe over to Subversion. The impetus was the inability to easily host a SourceSafe repository on the web and I grew tired of a co-worker or myself forgetting to do a check-in thus bringing development to a screeching halt.<br><br><br>The big reasons for picking subversion for us were:<br><br><br>1. Easily make repositories available via the web (tcp\ip). The built in svn server was a huge asset as well, no Apache or IIS config to worry about.<br><br><br>2. Solid support for renames/moves while keeping history.<br><br><br>3. How tags/branches are just diff copies so tags are super cheap.<br><br><br>4. Easy to script for automated builds using command-line.<br><br><br>5. Easy to setup on build machines, no license issues or activations to worry about when setting up a virtual build image or a separate build box.<br><br><br>6. Great UI with TortoiseSVN, integrates nicely with Explorer.<br><br><br>7. Great support for bug tracking integration with the bugtraq properties. We went with trac.<br><br><br>We use subversion to manage almost everything, and that includes all our websites, all our desktop apps and even all of our third-party components. The only issues we had were are first, before people were used to the morning update, nightly commit cycle. <br><br><br>I do run into some Delphi-specific annoyances, like the fact that every time you compile a COM DLL it re-writes the date/time into the comment section of the _TLB.pas file, which then makes it seem like the file needs committing or learning how to manage the .RES file, which again always changes. Now we just don't add the .res to the repository and instead build everything from .rc files. Those really have nothing to do with svn, just little quirks in managing a VCS.Shawn Osterhttp://a-simian-mind.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-50150179226950732112007-04-30T21:54:30.000-07:002007-04-30T21:54:30.000-07:00We use FreeVCS/JediVCS for a long long time now; r...We use FreeVCS/JediVCS for a long long time now; reasons where that it was free, but most important it allows you to directly get at the checked in files in the Database, which is nice if something goes horribly wrong.<br><br><br>That it's possible to store the archive in an Oracle DB was the ultimate argument for us, since we already have the infrastructure for Oracle up and running, including automated backups.<br><br><br>Since then we're kind of stuck with it, as we have so many projects in it. We've considered switching to other systems now and then (CVS earlier, SVN more recently), but our problems with JediVCS aren't big enough to make us actually switch.<br><br><br>Besides, the integration of SVN into the Delphi IDE isn't as good as what JediVCS has to offer. (At least the last time I checked, please correct me if I'm wrong.)<br><br><br>We prefer the serial model; but that might simply be that we're so used to it; a lot of my colleagues aren't trusting in the (automated) merging systems you have to use when going parallel.Holger Dorsnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-60603705693822244752007-05-01T03:44:39.000-07:002007-05-01T03:44:39.000-07:00which are the reason to CodeGear don't use sta...which are the reason to <a title="" href="http://www.codegear.com" rel="nofollow">CodeGear</a> don't use starteam?<br><br><br>is subversion + TortoiseSVN a better solution that Starteam?<br><br><br>kind regards<br><br>Frankdaniellodeito lodeironoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-10039784469028138162007-05-01T06:46:59.000-07:002007-05-01T06:46:59.000-07:00I prefer parallel development. We use Team Cohere...I prefer parallel development. We use Team Coherence here, but I use Subversion at home.<br><br><br>"One thing that I've noticed is that over the years version control systems are becoming more and more sophisticated and have finally begun to realized that version control is not just about files. It is also about configurations."<br><br><br>When are we going to be able to check in/out our Delphi configuration? :) I'd love to have packages, etc. based on relative file paths. <br><br><br>Changed dev machines? no problem, install Delphi, get the code/components/config from the version control server and go.<br><br><br>Added a new team member? No problem.<br><br><br>Brian Moelkhttp://www.brainendeavor.comnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-75797311582150892172007-05-01T20:21:51.000-07:002007-05-01T20:21:51.000-07:00We use CVS. When I started at current workplace, t...We use CVS. When I started at current workplace, they didn't use any VCS ! I did know CVS, so we decided to to use CVS.<br><br>Reasons:<br><br>1) Parallel<br><br>2) Affordable<br><br>3) UI topped with WinCVS<br><br><br>On top we use WinMerge as the diff tool.<br><br><br>Haven't looked at other systems, primarily because CVS works as expected for us.<br><br>PerPer Bakkendorffnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-91526265401093657002007-05-01T21:54:23.000-07:002007-05-01T21:54:23.000-07:00Hi,I have used several different VCSes at differen...Hi,<br><br><br>I have used several different VCSes at different companies:<br><br>1. none at all (really dangerous)<br><br>2. something written internally (hm, no, don't want to go back)<br><br>3. Perforce (reasonbly OK)<br><br>4. MS Sourcesafe (sucks big time)<br><br>5. CVS (better than 5. but ...)<br><br>6. SubVersion<br><br>7. FreeVCS<br><br>8. SubVersion<br><br><br>I had a say in the decisions 5. (SubVersion didn't exist then) and 8 and I am now fairly happy with using SubVersion + TortoiseSVN. Perforce was as OK as a VCS, but the UI sucked.<br><br><br>As for diff tools: Tortoise Merge is OK, but not great. I have always replaced it with BeyondCompare.<br><br><br>And since we are talking about Delphi and SubVersion: Could you please reduce the number of binary files (You said yourself: use text .dfms.)? I am thinking about the .res file in particular. I don't want to check it in because it changes with every build (autoinc buildno) but this change is already tracked by the .bdsproj file. But if I don't check it in, I lose the icon. Also it seems to be the master source for the version information, so everything in the .bdsproj file is overwritten if a .res file exists.<br><br><br>twm<br><br>Thomas Muellerhttp://www.dummzeuch.denoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-48214392780228722772007-05-01T22:59:37.000-07:002007-05-01T22:59:37.000-07:00Hi,We are currently using Visual Source Safe but a...Hi,<br><br><br>We are currently using Visual Source Safe but are about to upgrade to a different tool. This because Visual source safe has some major drawbacks: it tends to currupt and it does not allow you to do parallel development (without performing some tricks). Also the sharing model is only on file level.<br><br><br>Since we want a fast time to market and developing several projects at the same time, we want to support parallel development. We use the mainline model as base for version management.<br><br><br>In the selection of a new tool we had two serious candidates: Perforce and Starteam. In Perforce there is extensive support for integration with other bugcollection tools. But since our current bugcollector is not very stable any more because of the design limit of this tool(1 Gb), we chose Starteam. The possibilities for RFC's in Starteam fit our development proces.<br><br><br>grtz.<br><br><br>Diego Lonthttp://www.alex.nlnoreply@blogger.com