RE: [DUG] Source Control - Sharing files between projects
I don't have a need for a lot of this but I use WinMerge for 2way. http://winmerge.org/ Steve -Original Message- From: Myles Penlington [mailto:[EMAIL PROTECTED] Sent: Friday, 12 October 2007 8:45 a.m. To: NZ Borland Developers Group - Delphi List Subject: RE: [DUG] Source Control - Sharing files between projects Araxis rules for 2 3 way merge/diffs. Myles. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stacey Verner Sent: Friday, 12 October 2007 08:21 To: NZ Borland Developers Group - Delphi List Subject: RE: [DUG] Source Control - Sharing files between projects We use Araxis Merge for two way diff's and Tortoise Merge for 3 way merges. We found that Tortoise Merge automatically handles the merges much better than Araxis Merge, but Tortoise Merge is annoying when editing conflicts. You can't edit the text. You can only pick which lines you want to keep. Stacey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Mueller Sent: Thursday, 11 October 2007 19:40 To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Source Control - Sharing files between projects Never liked the clunky BeyondCompare - Araxis Merge is pricy but wins hands down. Here is one of my own take on making a diff-compare tool. Never really finished it into a full commercial standalone product, hesitant seeing that there are already heaps of free or cheap diff-tools out on the market: http://www.stefansblog.com/diffman/diffman.zip So how many of you guys are actually using any form of Diff-utility for your work? What are your favorite compare tools (Araxis, BeyondCompare, CompareIt,etc)? Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy North Sent: Thursday, October 11, 2007 1:15 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe Attention: This communication is confidential and may be legally privileged. If you are not the intended recipient, please do not use, disclose, copy or distribute it, other than to return it to us with your confirmation that it has been deleted from your system. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.8/1063 - Release Date: 11/10/2007 9:11 a.m. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Never liked the clunky BeyondCompare - Araxis Merge is pricy but wins hands down. Here is one of my own take on making a diff-compare tool. Never really finished it into a full commercial standalone product, hesitant seeing that there are already heaps of free or cheap diff-tools out on the market: http://www.stefansblog.com/diffman/diffman.zip So how many of you guys are actually using any form of Diff-utility for your work? What are your favorite compare tools (Araxis, BeyondCompare, CompareIt,etc)? Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy North Sent: Thursday, October 11, 2007 1:15 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
That one looks pretty cool.its not really a standalone program is it? ;) I would use it if it were. I remember many years ago that there were diff tools on unix that I imagine must have been made into graphical tools by now.there were diff and diff3 tools that could generate editor scripts to turn one file into another. I think these became the underlying code behind a lot of the source control engines, the ones that stored deltas or differences anyway, as they were all open source. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Mueller Sent: Thursday, 11 October 2007 7:40 p.m. To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Source Control - Sharing files between projects Never liked the clunky BeyondCompare - Araxis Merge is pricy but wins hands down. Here is one of my own take on making a diff-compare tool. Never really finished it into a full commercial standalone product, hesitant seeing that there are already heaps of free or cheap diff-tools out on the market: http://www.stefansblog.com/diffman/diffman.zip So how many of you guys are actually using any form of Diff-utility for your work? What are your favorite compare tools (Araxis, BeyondCompare, CompareIt,etc)? Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy North Sent: Thursday, October 11, 2007 1:15 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
We use Araxis Merge for two way diff's and Tortoise Merge for 3 way merges. We found that Tortoise Merge automatically handles the merges much better than Araxis Merge, but Tortoise Merge is annoying when editing conflicts. You can't edit the text. You can only pick which lines you want to keep. Stacey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Mueller Sent: Thursday, 11 October 2007 19:40 To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Source Control - Sharing files between projects Never liked the clunky BeyondCompare - Araxis Merge is pricy but wins hands down. Here is one of my own take on making a diff-compare tool. Never really finished it into a full commercial standalone product, hesitant seeing that there are already heaps of free or cheap diff-tools out on the market: http://www.stefansblog.com/diffman/diffman.zip So how many of you guys are actually using any form of Diff-utility for your work? What are your favorite compare tools (Araxis, BeyondCompare, CompareIt,etc)? Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy North Sent: Thursday, October 11, 2007 1:15 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Araxis rules for 2 3 way merge/diffs. Myles. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stacey Verner Sent: Friday, 12 October 2007 08:21 To: NZ Borland Developers Group - Delphi List Subject: RE: [DUG] Source Control - Sharing files between projects We use Araxis Merge for two way diff's and Tortoise Merge for 3 way merges. We found that Tortoise Merge automatically handles the merges much better than Araxis Merge, but Tortoise Merge is annoying when editing conflicts. You can't edit the text. You can only pick which lines you want to keep. Stacey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Mueller Sent: Thursday, 11 October 2007 19:40 To: 'NZ Borland Developers Group - Delphi List' Subject: RE: [DUG] Source Control - Sharing files between projects Never liked the clunky BeyondCompare - Araxis Merge is pricy but wins hands down. Here is one of my own take on making a diff-compare tool. Never really finished it into a full commercial standalone product, hesitant seeing that there are already heaps of free or cheap diff-tools out on the market: http://www.stefansblog.com/diffman/diffman.zip So how many of you guys are actually using any form of Diff-utility for your work? What are your favorite compare tools (Araxis, BeyondCompare, CompareIt,etc)? Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy North Sent: Thursday, October 11, 2007 1:15 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe Attention: This communication is confidential and may be legally privileged. If you are not the intended recipient, please do not use, disclose, copy or distribute it, other than to return it to us with your confirmation that it has been deleted from your system. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Hi Paul, Sorry to resurrect an oldish thread but... I've been told by a couple of the guys here who were reviewing the Perforce Trial that the merge/resolve tool which comes with Perforce is crap. They then qualified it by saying that if you were used to text only unix compare programs then you might like it. As we are used to nice graphical three panel compare/merge programs (ie version1 left, version2 right, merged bottom) this isn't really us. What merge/resolve tool do you (and others) use for Perforce? The built in Perforce text only tool or a 3rd party tool? Or have we missed something (keeping in mind that I haven't actually seen what they are talking about myself yet!) Thanks, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Heinz Sent: Wednesday, 26 September 2007 10:14 p.m. To: NZ Borland Developers Group - Delphi List Subject: RE: [DUG] Source Control - Sharing files between projects Berend wrote: Exactly, you branch the /Reference/Core1 to /Project1/Core1 David But my interpretation of your model is that you are relying David on editing each of the core files within the Reference David branches and then merging through to the Project David branches. No, the reverse. You edit /Project1/Core1 and merge the changes back to /Reference/Core1 when stable/convenient. Perforce handles such merge back really well, unlike more primitive tools. David Furthermore it is while editing one of the projects that David you would want to change one of the core files. And you do it exactly there. David And if developers are editing the core files a various David project branches then how do you get each of these changes David reliably merged into the other 7 projects? You merge the /Project1/Core1 into /Reference/Core1. Project2 developers can merge newer versions of /Reference/Core1 into /Project2/Core1 when convenient. David Unless there is some easy way of automating or at least David semi-automating this in Perforce? Perforce won't bother you with merges you already did. Just for completeness, note that you don't have to do it this way - i.e. with lots of merging back and forth, although Berend is correct, Perforce is *very good* at handling merging, especially in both directions. You can have the _exact same_ versioned files checked out into multiple project workspaces without any branching or merging - just workspace mappings. Then, _any changes_ committed to those shared files are changing those files for _all projects_ with no merging back and forth necessary. That may not be the model you desire however as the branch and merge model does provide more change isolation. Perforce supports both ways of working, essentially. TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
David asked: Hi Paul, Sorry to resurrect an oldish thread but... I've been told by a couple of the guys here who were reviewing the Perforce Trial that the merge/resolve tool which comes with Perforce is crap. They then qualified it by saying that if you were used to text only unix compare programs then you might like it. As we are used to nice graphical three panel compare/merge programs (ie version1 left, version2 right, merged bottom) this isn't really us. Yeah - it's serviceable (maybe) but not great. I don't use it. What merge/resolve tool do you (and others) use for Perforce? The built in Perforce text only tool or a 3rd party tool? Or have we missed something (keeping in mind that I haven't actually seen what they are talking about myself yet!) Araxis Merge is fan-friggin-tastic. And it's has special helper exes designed to plug into Perforce. There are probably others tools that are OK too, and admittedly, Araxis isn't cheap but it's worth it. Mostly I like Araxis as it has this neat 'do all the easy merge chunks' button and then it will let me step back and fortyh through the remaining conflicts (which are usually only a few chunks) and resolve them manually with a few keystrokes.. Anything to make merging easier is worth having IMO. TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. cheers, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Jeremy wrote: I've blogged about it before but I really like BeyondCompare. The upcoming version 3 sounds very promising on the merge front and 3 way compares. I expect both have trials. Yes, for a two-way tool Beyond Compare is really nice and we use it in-house too by our support staff with normal diff and compare stuff. But it's lack of powerful three-way compare/merge support ruled it out for my use with Perforce when I was comparing it and Araxis. It sounds like Beyond Compare may finally get some good 3-way support, I seem to remember the developer has been talking about it for a while. (Beyond Compare is written in Delphi I believe). It might be good, but then Araxis has been doing the 3-way dance for some time and it shows. There was another 3-way tool (the name escapes me - it was 5 or so years ago :-) I saw that looked powerful, but it was written in Java to be portable and the UI (Swing I think) was pretty clunky and had weak keyboard handling, so Araxis being Win32 native won the day. I seem to remember it comes bundled with SurroundSCM as their merge tool. Perforce hasn't focussed on shipping a best of breed merge/compare tools - which is not to say their tool doesn't work - it's just not a primary focus. Instead, they tend to focus on their knitting (the core SCM engine) and let the market and customer decide which 3rd party tools they prefer. TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David == David Brennan [EMAIL PROTECTED] writes: David Does Perforce make it fairly easy to see which changes have David occurred in a branch and have NOT yet been merged back into David another branch (ie back into the Reference branch)? Yes, either command-line (all), or a nice diff tool. David Also, is it fairly easy (in Perforce) to only branch off David some of the files in the reference subfolder to the project David subfolder, instead of all of them? Yes, but a bit laborious. You can create branch specs to automate that, but beyond a dozen files I would reorganise my folders. - -- Live long and prosper, Berend de Boer PS: This email has been digitally signed if you wonder what the strange characters are that your email client displays. PGP public key: http://www.pobox.com/~berend/berend-public-key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFG+h7gIyuuaiRyjTYRAoWbAJwPV1V5oDk3DLZ/DlGbSh182hS8sgCgrz/o H0mKM427tf7wkRHCTXTLjNU= =bRYk -END PGP SIGNATURE- ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul == Paul Heinz [EMAIL PROTECTED] writes: Paul Once Subversion finally gets merge history tracking, it Paul might become usable for true codeline management but Paul Perforce is also *fast* especially over a WAN/VPN link, and Paul has earned an enviable reputation for rock solid Paul reliability. Subversion has a fair ways to go on those Paul fronts All excellent points Paul. Perforce is just way ahead. I'm a real command-line guy, but I love the Perforce GUI. It's fast, never had a problem, works on every platform, truly an outstanding product. - -- Live long and prosper, Berend de Boer PS: This email has been digitally signed if you wonder what the strange characters are that your email client displays. PGP public key: http://www.pobox.com/~berend/berend-public-key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFG+h9RIyuuaiRyjTYRAuwFAJwK5r81IM6rVAlC2nLy2hCLnMaVUgCfRWcq ZQQZ5TrYs1LBp22wy+s6mKE= =9RZF -END PGP SIGNATURE- ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Berend wrote: Exactly, you branch the /Reference/Core1 to /Project1/Core1 David But my interpretation of your model is that you are relying David on editing each of the core files within the Reference David branches and then merging through to the Project David branches. No, the reverse. You edit /Project1/Core1 and merge the changes back to /Reference/Core1 when stable/convenient. Perforce handles such merge back really well, unlike more primitive tools. David Furthermore it is while editing one of the projects that David you would want to change one of the core files. And you do it exactly there. David And if developers are editing the core files a various David project branches then how do you get each of these changes David reliably merged into the other 7 projects? You merge the /Project1/Core1 into /Reference/Core1. Project2 developers can merge newer versions of /Reference/Core1 into /Project2/Core1 when convenient. David Unless there is some easy way of automating or at least David semi-automating this in Perforce? Perforce won't bother you with merges you already did. Just for completeness, note that you don't have to do it this way - i.e. with lots of merging back and forth, although Berend is correct, Perforce is *very good* at handling merging, especially in both directions. You can have the _exact same_ versioned files checked out into multiple project workspaces without any branching or merging - just workspace mappings. Then, _any changes_ committed to those shared files are changing those files for _all projects_ with no merging back and forth necessary. That may not be the model you desire however as the branch and merge model does provide more change isolation. Perforce supports both ways of working, essentially. TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
If you like VSS but want to have a real db backend, you might want to look at JEDI Version Control System http://jedivcs.sourceforge.net/, an Open Source project. Cheers, Kuet-Fung From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brennan Sent: Wednesday, 26 September 2007 10:12 To: 'NZ Borland Developers Group - Delphi List' Subject: [DUG] Source Control - Sharing files between projects Hi, I'm interested in hearing how people use their source control. We currently use Visual SourceSafe (VSS) which it turns out (after some comparison with other options) is quite nice in terms of core feature set. However is isn't a true database with atomic commits so there is that constant risk of database corruption if a network connection dies. We've been pretty luck so far but we have had one fairly minor scare. It also lacks strong support for branching and changeset type changes. So I can certainly see benefits in moving to a more powerful tool. The problem is that the alternatives all seem to be missing one or more VSS features. For example I don't like Subversion/CVS because their lack of explicit checkouts means you can't tell which developers are working on a particular file (unless you use Subversion locks but then only one developer can edit the file at once, unlike VSS's multiple checkouts). So the current favourite is probably Perforce. I know several companies on DUG (most notably Accredo) use and love Perforce. It looks great. Costs a bit but we can probably handle that. The one feature it appears to be missing is Shared Files. To explain, VSS allows you to share a file between multiple folders. We have maybe a dozen Delphi projects and most of our source files are used by more than one project. That's fine, we put each project into a different VSS folder and share the files to the projects which require them. Unfortunately this appears to be a VSS specific ability. So the questions: 1. Does anyone know how to reliably achieve similar shared file between folders functionality in Perforce? 2. Most development companies must have similar shared source files. How do you structure your projects and source files? (Note: I am talking about source files used by projects here, not files which are compiled into VCL packages) Some thoughts on question 2: One option is to just put all files into a single directory. No need to share now! However this means that projects could easily end up compiling in files you don't think they are (or should be) using because Delphi will always find the file. With our current separate folders scheme there is some control and you can be fairly sure whether a project is or is not using a source file. Another option would be to put the projects in one directory, the source files in one or more other directories, and then get the projects to reference each source file by relative path. This way each project will only be able to compile in files which are specifically referenced in the project file so you can easily check which files are being used. The downside of this (and the previous option too) is that each project is directly sharing the files with the others. So if you are making multiple changes in one project over the period of a week or so then it quite probable that none of your other projects will compile until you are finished because they will be trying to compile in your changed files. This is particularly frustrating if you need to make a small unrelated change to another project midway through the week. So... what's a developer to do!? Cheers, David. CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorised disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David == David Brennan [EMAIL PROTECTED] writes: David We currently use Visual SourceSafe (VSS) which it turns out David (after some comparison with other options) is quite nice in David terms of core feature set. However is isn't a true David database with atomic commits so there is that constant risk David of database corruption if a network connection dies. We've David been pretty luck so far but we have had one fairly minor David scare. It also lacks strong support for branching and David changeset type changes. Hmm, nice in terms of core feature set, but somehow misses all the things that are essential to a decent source code control tool :-) David So the current favourite is probably Perforce. I use it, I love it. David 1. Does anyone know how to reliably achieve similar shared David file between folders functionality in Perforce? It doesn't have this feature, because it doesn't work. With this feature you can no longer reliable track changes to a branch or a product. David 2. Most development companies must have similar shared David source files. How do you structure your projects and source David files? (Note: I am talking about source files used by David projects here, not files which are compiled into VCL David packages) I always branch every single library to a product or products directory. So you know exactly what you've got. You don't have to recompile (or find out with a full build) that your library update broke dozens of other projects. It allows very fine-grained and controlled migrations of libraries. Read this portion of the SVN handbook: http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html Which explains the concepts. David So. what's a developer to do!? Make sure he can track every single line of code change to a binary. - -- Cheers, Berend de Boer PS: This email has been digitally signed if you wonder what the strange characters are that your email client displays. PGP public key: http://www.pobox.com/~berend/berend-public-key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFG+YzLIyuuaiRyjTYRApm3AKCxj4c3wffA89bH+IhWnSdPyw9JAACgxSkk 4xr35k83n3Iw1c0VsJ2bmek= =Cu1T -END PGP SIGNATURE- ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Some quick thoughts. We've just made the move from VSS to Subversion (with TortoiseSVN). We've got rid of all our shared files. There were only a few, so we've put them in a common folder. I suppose an alternative if you've been making extensive use of shared files, would be to put them in a separate repository, and use an svn:externals property to pull the shared stuff from the separate repository into an appropriate folder in the working copy of each of your other repositories. Also, my understanding is that Subversion locks aren't actually locks as such. They're more an indication that another user is currently working on a file, but there's apparently nothing in Subversion which will actually prevent multiple developers from ignoring that lock if they wish, and modifying and committing changes to a file locked by somebody else. This is my understanding so far; we haven't got far enough into it to have experienced that in anger. HTH, Conor From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brennan I'm interested in hearing how people use their source control. We currently use Visual SourceSafe (VSS) which it turns out (after some comparison with other options) is quite nice in terms of core feature set. However is isn't a true database with atomic commits so there is that constant risk of database corruption if a network connection dies. We've been pretty luck so far but we have had one fairly minor scare. It also lacks strong support for branching and changeset type changes. So I can certainly see benefits in moving to a more powerful tool. The problem is that the alternatives all seem to be missing one or more VSS features. For example I don't like Subversion/CVS because their lack of explicit checkouts means you can't tell which developers are working on a particular file (unless you use Subversion locks but then only one developer can edit the file at once, unlike VSS's multiple checkouts). So the current favourite is probably Perforce. I know several companies on DUG (most notably Accredo) use and love Perforce. It looks great. Costs a bit but we can probably handle that. The one feature it appears to be missing is Shared Files. To explain, VSS allows you to share a file between multiple folders. We have maybe a dozen Delphi projects and most of our source files are used by more than one project. That's fine, we put each project into a different VSS folder and share the files to the projects which require them. Unfortunately this appears to be a VSS specific ability. So the questions: 1. Does anyone know how to reliably achieve similar shared file between folders functionality in Perforce? 2. Most development companies must have similar shared source files. How do you structure your projects and source files? (Note: I am talking about source files used by projects here, not files which are compiled into VCL packages) Some thoughts on question 2: One option is to just put all files into a single directory. No need to share now! However this means that projects could easily end up compiling in files you don't think they are (or should be) using because Delphi will always find the file. With our current separate folders scheme there is some control and you can be fairly sure whether a project is or is not using a source file. Another option would be to put the projects in one directory, the source files in one or more other directories, and then get the projects to reference each source file by relative path. This way each project will only be able to compile in files which are specifically referenced in the project file so you can easily check which files are being used. The downside of this (and the previous option too) is that each project is directly sharing the files with the others. So if you are making multiple changes in one project over the period of a week or so then it quite probable that none of your other projects will compile until you are finished because they will be trying to compile in your changed files. This is particularly frustrating if you need to make a small unrelated change to another project midway through the week. So... what's a developer to do!? Cheers, David. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
We are using subversion and it has the same problem. We re-arranged our project structure so that there is a folder that contains all of the common code which is well organised into sub folders. Each projects folder actually contains a minimal set of files that are currently, and always going to be, completely unique to that project. Sometimes this is just the main form. The rest of the files are under Common. The project uses clause contains a list of every file in the project with relative paths. Files for components are'nt listed in the project because they are in folders that are in our Library path. You mentioned that it may be a problem for all projects to share the same copy of a file, but I think it works better this way. In this case you can make the changes to your file, and then make sure it works with other project before checking things in. When the files were shared it was pretty common for someone to check is a change that worked with one project, but not with another. The only thing that this doesn't handle is files that are shared between each project that are not compiled into the exe, such as help files. In subversion you can share folders (using svn-externals), so we have a common folder that contains these files and share this folder with each project that needs them. Again this has actually improved things because these files are nicely organised into sub folders rather than all being in the same folder as the exe. Stacey From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Brennan Sent: Wednesday, 26 September 2007 10:12 To: 'NZ Borland Developers Group - Delphi List' Subject: [DUG] Source Control - Sharing files between projects Hi, I'm interested in hearing how people use their source control. We currently use Visual SourceSafe (VSS) which it turns out (after some comparison with other options) is quite nice in terms of core feature set. However is isn't a true database with atomic commits so there is that constant risk of database corruption if a network connection dies. We've been pretty luck so far but we have had one fairly minor scare. It also lacks strong support for branching and changeset type changes. So I can certainly see benefits in moving to a more powerful tool. The problem is that the alternatives all seem to be missing one or more VSS features. For example I don't like Subversion/CVS because their lack of explicit checkouts means you can't tell which developers are working on a particular file (unless you use Subversion locks but then only one developer can edit the file at once, unlike VSS's multiple checkouts). So the current favourite is probably Perforce. I know several companies on DUG (most notably Accredo) use and love Perforce. It looks great. Costs a bit but we can probably handle that. The one feature it appears to be missing is Shared Files. To explain, VSS allows you to share a file between multiple folders. We have maybe a dozen Delphi projects and most of our source files are used by more than one project. That's fine, we put each project into a different VSS folder and share the files to the projects which require them. Unfortunately this appears to be a VSS specific ability. So the questions: 1. Does anyone know how to reliably achieve similar shared file between folders functionality in Perforce? 2. Most development companies must have similar shared source files. How do you structure your projects and source files? (Note: I am talking about source files used by projects here, not files which are compiled into VCL packages) Some thoughts on question 2: One option is to just put all files into a single directory. No need to share now! However this means that projects could easily end up compiling in files you don't think they are (or should be) using because Delphi will always find the file. With our current separate folders scheme there is some control and you can be fairly sure whether a project is or is not using a source file. Another option would be to put the projects in one directory, the source files in one or more other directories, and then get the projects to reference each source file by relative path. This way each project will only be able to compile in files which are specifically referenced in the project file so you can easily check which files are being used. The downside of this (and the previous option too) is that each project is directly sharing the files with the others. So if you are making multiple changes in one project over the period of a week or so then it quite probable that none of your other projects will compile until you are finished because they will be trying to compile in your changed files. This is particularly frustrating if you need to make a small unrelated change to another project midway through the week. So... what's a developer to do!? Cheers, David. ___ NZ
Re: [DUG] Source Control - Sharing files between projects
We are currently using Subversion but are moving now to Surround SCM (http://www.seapine.com/surroundscm.html). Our uses are more for binary files than source files so this was a bigger driver in the search. One note, I looked seriously at VSS as I've used it before but with all the reports of the unstable database, I'm glad I didn't go there. Steve -- Steve Peacocke http://stevepeacocke.blogspot.com/ ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Comments below... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Berend de Boer Sent: Wednesday, 26 September 2007 10:34 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects Hmm, nice in terms of core feature set, but somehow misses all the things that are essential to a decent source code control tool :-) Heh. One would have thought so given how much it gets dumped on but it has worked very well for us, with the risk of corruption being the only real concern. However once we have moved to a system which supports proper branching and changesets I'm sure we will look back and wonder why it worked so well! I always branch every single library to a product or products directory. So you know exactly what you've got. You don't have to recompile (or find out with a full build) that your library update broke dozens of other projects. It allows very fine-grained and controlled migrations of libraries. Read this portion of the SVN handbook: http://svnbook.red- bean.com/en/1.4/svn.advanced.vendorbr.html So by my understanding you are talking about effectively sharing code between your product directories BUT not having the sharing happen automatically. Instead you are triggering the sharing (really merging) from a central control point for that code only when you want to. The example in the link was for an external library and I can see that working well. I'm not so sure it is applicable to what I am talking about. This isn't library code, it is frequently changing core code which needs to be shared between say 8 other projects which use the same code. It must be edited within one of those projects in order for changes to make sense. Potentially you will want to perform the edit in any of the 8 projects because the edit is part of a larger change that is centred in that project. So either you have to manually merge that change into each of the 7 other project branches when you check it in OR you have a situation where 8 branches projects are all having disjoint changes occurring. I don't imagine this is what you were suggesting... ;-) So if you have time I would love to hear what you mean? David. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
David asked: 1. Does anyone know how to reliably achieve similar shared file between folders functionality in Perforce? Yes, you can map the same file(s) into multiple work spaces (or clientspecs in Perforce terms) to use them in multiple projects. It's a different technique but it should probably offer you the intended results. I'd also stronhly recommend getting a copy of the book 'Practical Perforce' from Amazon which was recently written by one of the Perforce architects (Laura Wingerd). It covers questions like this which crop up often and possibly many others you may have too. 2. Most development companies must have similar shared source files. How do you structure your projects and source files? (Note: I am talking about source files used by projects here, not files which are compiled into VCL packages) Yeah. It's a bit awkward in Delphi (well in D7 and earlier) due to the way Delphi futzes with paths that move up from the project directory and then back down in to a shared directory across projects. So, we moved to having a top level folder which the .dprs sit in and then a Products (aka Projects) folder containing the unique units and a Common folder containing the shared units. This seems to work pretty well so far. TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
On Wed, 26 Sep 2007 10:12:11 +1200, you wrote: snip 2. Most development companies must have similar shared source files. How do you structure your projects and source files? (Note: I am talking about source files used by projects here, not files which are compiled into VCL packages) Use a branch/project layout rather than a project/branch structure E.g. /trunk/common /trunk/proj1 /trunk/proj2 /branches/common /branches/proj1 /branches/proj2 /tags/common /tags/proj1 /tags/proj2 HTH D ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David == David Brennan [EMAIL PROTECTED] writes: David So by my understanding you are talking about effectively David sharing code between your product directories BUT not David having the sharing happen automatically. Instead you are David triggering the sharing (really merging) from a central David control point for that code only when you want to. Yes, with many different developers working in different binaries (for example GUI and backend) I've found that not having one checkin break the whole world, worked perfectly well. So at controlled moments in time developers can grab updates (merge them). David The example in the link was for an external library and I David can see that working well. I'm not so sure it is applicable David to what I am talking about. This isn't library code, it is David frequently changing core code which needs to be shared David between say 8 other projects which use the same code. It David must be edited within one of those projects in order for David changes to make sense. Potentially you will want to David perform the edit in any of the 8 projects because the edit David is part of a larger change that is centred in that project. David So either you have to manually merge that change into each David of the 7 other project branches when you check it in OR you David have a situation where 8 branches projects are all having David disjoint changes occurring. David I don't imagine this is what you were suggesting... ;-) David So if you have time I would love to hear what you mean? If you are the sole developer, you can have a common directory that all these 8 projects use. No need to branch this common code to the 8 projects. But it's not an approach that does scale. So it depends on the size of your team. - -- All the best, Berend de Boer PS: This email has been digitally signed if you wonder what the strange characters are that your email client displays. PGP public key: http://www.pobox.com/~berend/berend-public-key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFG+aLiIyuuaiRyjTYRAlzEAKCSbE7tz5pOEz/rmy6+14r71S/MNgCgyrmO nwgwwV7ZUbIKWipi9svrFR0= =9ckw -END PGP SIGNATURE- ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
David The example in the link was for an external library and I David can see that working well. I'm not so sure it is applicable David to what I am talking about. This isn't library code, it is David frequently changing core code which needs to be shared David between say 8 other projects which use the same code. It David must be edited within one of those projects in order for David changes to make sense. Potentially you will want to David perform the edit in any of the 8 projects because the edit David is part of a larger change that is centred in that project. David So either you have to manually merge that change into each David of the 7 other project branches when you check it in OR you David have a situation where 8 branches projects are all having David disjoint changes occurring. David I don't imagine this is what you were suggesting... ;-) David So if you have time I would love to hear what you mean? If you are the sole developer, you can have a common directory that all these 8 projects use. No need to branch this common code to the 8 projects. But it's not an approach that does scale. So it depends on the size of your team. I agree... but what is the approach that scales! I am still not getting you. These are files that cannot be edited independently of a core project (unlike say vcl library files). And you can legitimately want to edit them from the context of each of the 8 projects. For an example I think you are proposing: /Reference/Core1 /Reference/Core2, 3... etc /Project1/Unique /Project1/Core1 /Project1/Core2, 3... etc /Project2/Unique /Project2/Core1 /Project2/Core2, 3... etc ... through to project 8. But my interpretation of your model is that you are relying on editing each of the core files within the Reference branches and then merging through to the Project branches. But these are source files that cannot be compiled into anything meaningful unless you are editing one of the projects. Furthermore it is while editing one of the projects that you would want to change one of the core files. And if developers are editing the core files a various project branches then how do you get each of these changes reliably merged into the other 7 projects? Unless there is some easy way of automating or at least semi-automating this in Perforce? David. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Source Control - Sharing files between projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David == David Brennan [EMAIL PROTECTED] writes: David I am still not getting you. These are files that cannot be David edited independently of a core project (unlike say vcl David library files). And you can legitimately want to edit them David from the context of each of the 8 projects. David For an example I think you are proposing: Exactly, you branch the /Reference/Core1 to /Project1/Core1 David But my interpretation of your model is that you are relying David on editing each of the core files within the Reference David branches and then merging through to the Project David branches. No, the reverse. You edit /Project1/Core1 and merge the changes back to /Reference/Core1 when stable/convenient. Perforce handles such merge back really well, unlike more primitive tools. David Furthermore it is while editing one of the projects that David you would want to change one of the core files. And you do it exactly there. David And if developers are editing the core files a various David project branches then how do you get each of these changes David reliably merged into the other 7 projects? You merge the /Project1/Core1 into /Reference/Core1. Project2 developers can merge newer versions of /Reference/Core1 into /Project2/Core1 when convenient. David Unless there is some easy way of automating or at least David semi-automating this in Perforce? Perforce won't bother you with merges you already did. - -- All the best, Berend de Boer PS: This email has been digitally signed if you wonder what the strange characters are that your email client displays. PGP public key: http://www.pobox.com/~berend/berend-public-key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFG+bYRIyuuaiRyjTYRAgooAJ46C4Jzl4f6qpjAhDi27SW1zzM+awCeOGb+ V5f3P73f7yMWvfhTRN7oz9o= =ijw6 -END PGP SIGNATURE- ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Thanks Berend. That clarifies what you were meaning. A large part of working out how best to restructure our source control is coming to understand what the options are, hence my questions ;-). A couple of little questions for Berend, Paul or anyone else using Perforce. Does Perforce make it fairly easy to see which changes have occurred in a branch and have NOT yet been merged back into another branch (ie back into the Reference branch)? Also, is it fairly easy (in Perforce) to only branch off some of the files in the reference subfolder to the project subfolder, instead of all of them? Cheers, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Berend de Boer Sent: Wednesday, 26 September 2007 1:30 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David == David Brennan [EMAIL PROTECTED] writes: David I am still not getting you. These are files that cannot be David edited independently of a core project (unlike say vcl David library files). And you can legitimately want to edit them David from the context of each of the 8 projects. David For an example I think you are proposing: Exactly, you branch the /Reference/Core1 to /Project1/Core1 David But my interpretation of your model is that you are relying David on editing each of the core files within the Reference David branches and then merging through to the Project David branches. No, the reverse. You edit /Project1/Core1 and merge the changes back to /Reference/Core1 when stable/convenient. Perforce handles such merge back really well, unlike more primitive tools. David Furthermore it is while editing one of the projects that David you would want to change one of the core files. And you do it exactly there. David And if developers are editing the core files a various David project branches then how do you get each of these changes David reliably merged into the other 7 projects? You merge the /Project1/Core1 into /Reference/Core1. Project2 developers can merge newer versions of /Reference/Core1 into /Project2/Core1 when convenient. David Unless there is some easy way of automating or at least David semi-automating this in Perforce? Perforce won't bother you with merges you already did. - -- All the best, Berend de Boer PS: This email has been digitally signed if you wonder what the strange characters are that your email client displays. PGP public key: http://www.pobox.com/~berend/berend-public-key.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFG+bYRIyuuaiRyjTYRAgooAJ46C4Jzl4f6qpjAhDi27SW1zzM+awCeOGb+ V5f3P73f7yMWvfhTRN7oz9o= =ijw6 -END PGP SIGNATURE- ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
David wrote: Thanks Berend. That clarifies what you were meaning. A large part of working out how best to restructure our source control is coming to understand what the options are, hence my questions ;-). A couple of little questions for Berend, Paul or anyone else using Perforce. Does Perforce make it fairly easy to see which changes have occurred in a branch and have NOT yet been merged back into another branch (ie back into the Reference branch)? Yes, very easily but it's not necessarily organised the way you might like (i.e. in my case, files grouped into individual changesets, and sorted by changeset). But Perforce is very automatable/scriptable so I wrote a Delphi app which did the necessary twiddling. There is an undocumented command (it's mentioned in the Perforce book) that does more of what I wanted but having written the tool, it actually does more heavy lifting than they do so I prefer it. Since then I've gone even further by scripting Perforce using Python (there's actually two Python interface libraries for Perforce now). These scripts handle all my multiple codeline merge tasks relatively effortlessly which was tedious to do via the GUI or command line. Mind you, that only gets to be an issue when you're handling 6 code lines at once (i.e. 3 releases being worked on in parallel (prior, current, future) x 2 promotion stages). As a general approach, Perforce focusses on getting the core operations fast and rock-solid and then allowing you to automate it to meet your particulat (and peculiar) requirements rather than forcing you to live within the limits of some pre-supplied GUI and command line tools. I personally prefer that kind of product (Accredo follows essentially the same philosophy) but others will have different preferences. Once Subversion finally gets merge history tracking, it might become usable for true codeline management but Perforce is also *fast* especially over a WAN/VPN link, and has earned an enviable reputation for rock solid reliability. Subversion has a fair ways to go on those fronts Also, is it fairly easy (in Perforce) to only branch off some of the files in the reference subfolder to the project subfolder, instead of all of them? Yes, at it's core, Perforce does file level branch and merging. Folder level is a client/UI convenience :-) TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Thanks Paul. We'll be downloading the Perforce demo and playing with it once we get the current release out the door ;-) Cheers, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Heinz Sent: Wednesday, 26 September 2007 3:50 p.m. To: NZ Borland Developers Group - Delphi List Subject: RE: [DUG] Source Control - Sharing files between projects David wrote: Thanks Berend. That clarifies what you were meaning. A large part of working out how best to restructure our source control is coming to understand what the options are, hence my questions ;-). A couple of little questions for Berend, Paul or anyone else using Perforce. Does Perforce make it fairly easy to see which changes have occurred in a branch and have NOT yet been merged back into another branch (ie back into the Reference branch)? Yes, very easily but it's not necessarily organised the way you might like (i.e. in my case, files grouped into individual changesets, and sorted by changeset). But Perforce is very automatable/scriptable so I wrote a Delphi app which did the necessary twiddling. There is an undocumented command (it's mentioned in the Perforce book) that does more of what I wanted but having written the tool, it actually does more heavy lifting than they do so I prefer it. Since then I've gone even further by scripting Perforce using Python (there's actually two Python interface libraries for Perforce now). These scripts handle all my multiple codeline merge tasks relatively effortlessly which was tedious to do via the GUI or command line. Mind you, that only gets to be an issue when you're handling 6 code lines at once (i.e. 3 releases being worked on in parallel (prior, current, future) x 2 promotion stages). As a general approach, Perforce focusses on getting the core operations fast and rock-solid and then allowing you to automate it to meet your particulat (and peculiar) requirements rather than forcing you to live within the limits of some pre-supplied GUI and command line tools. I personally prefer that kind of product (Accredo follows essentially the same philosophy) but others will have different preferences. Once Subversion finally gets merge history tracking, it might become usable for true codeline management but Perforce is also *fast* especially over a WAN/VPN link, and has earned an enviable reputation for rock solid reliability. Subversion has a fair ways to go on those fronts Also, is it fairly easy (in Perforce) to only branch off some of the files in the reference subfolder to the project subfolder, instead of all of them? Yes, at it's core, Perforce does file level branch and merging. Folder level is a client/UI convenience :-) TTFN, Paul. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
RE: [DUG] Source Control - Sharing files between projects
Hi all, Interested to know whether anybody is using Team Foundation Server (TFS). Thanks, Sabu M H _ From: [EMAIL PROTECTED] on behalf of Steve Peacocke Sent: Wed 9/26/2007 5:01 AM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Source Control - Sharing files between projects We are currently using Subversion but are moving now to Surround SCM (http://www.seapine.com/surroundscm.html). Our uses are more for binary files than source files so this was a bigger driver in the search. One note, I looked seriously at VSS as I've used it before but with all the reports of the unstable database, I'm glad I didn't go there. Steve -- Steve Peacocke http://stevepeacocke.blogspot.com/ ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe iGATE is ranked as 3rd best IT employer in India as per DQ-IDC Best Employer Survey-2007 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Information transmitted by this EMAIL is proprietary to iGATE Group of Companies and is intended for use only by the individual or entity to whom it is addressed and may contain information that is privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient of this EMAIL immediately notify the sender at iGATE or [EMAIL PROTECTED] and delete this EMAIL including any attachments _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
