I second Mike's comment about SVN. I like Perforce but once I got used to SVN I liked it's price better ;-)
The only thing I found a pain about SVN was that you can't tell who else has an item checked out...so I ended up creating a wrapper utility for that. On Aug 2, 10:32 am, Simon Verona <[email protected]> wrote: > Jim > > Thanks for that, I have downloaded perforce server but wanted to get > some idea on what the end-game would look like rather than experimenting > until I get it right! > > Regards > Simon > > On 02/08/2010 18:17, Jim Idle wrote: > > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Simon Verona > >> Sent: Sunday, August 01, 2010 2:55 PM > >> To: [email protected] > >> Subject: Using Perforce SCM with jBASE > > >> Hi > > >> I'm looking of migrating our source control from our own home grown > >> system to a "proper" SCM. > > >> I'm looking at Perforce, as it's the one Jim always advises I should > > use... It > >> supports a command line API as well as working with Visual Studio as a > > plug- > >> in for our dotnet software. > > Yes - it works very well indeed - the only proviso is that you need to start > > working the way it expects you to (which is in fact a really good way and > > not the equivalent say of suddenly changing your business to SAP rules). If > > you don't want to pay for something as good as perforce then use SVN (don't > > even bother looking at the others), though you lose quite a lot in terms of > > simplicity and only Perforce has the 'correct' model of knowing what > > everyone is doing at the server side instead of just letting everyone do > > whatever they want locally. > > >> I'm looking at the command line interface and thinking of the best way of > >> implementing. Currently, we have a single centralised server where we > >> directly edit our databasic code. We only have 3 developers. We don't > > use > >> check-in/check-out currently - and the process of making software releases > >> is much more informal - "Are all code changes > >> complete". We have been lucky, as this has always worked well. > > Yeah - you are two over the limit of how many people you need for this to go > > wrong ;-). > > >> I'm looking for some advice as to how to best implement P4 into this > >> environment. It looks like I can build a simple source code control > > "shell" > >> around the P4 CLI commands to check in/check out code from the > >> Perforce system. However, I'm not sure how we can then make software > >> revisions - I presume we do this from the Perforce repository.. > > You don't even need that really, as you are using Windows, just use the p4v > > GUI. All you need (and MUST) do is place your source code in directories and > > not hash files. I would avoid using any wrappers and just learn the p4 > > commands - you only need a few. > > >> As you can probably see, I'm confused. I've read some of the html > >> online guides for Perforce but there are some assumptions are made that > >> the user knows about source control systems. > > I think that there is a book that is much easier to get your head around. > > >> I seem to think that Perforce almost assumes that every user has their own > >> full copy of the softwar environment (ie a local copy of jBase and all the > >> source code) and then checks out the code they want to edit from > >> the Perforce server, checking it back in when complete. Is this > >> correct? Do I presume therefore that regularly, all checked-in code > >> needs to be distributed to all development servers ??? > > >> Am I even close on how this would work ? > > Yes - you are nearly there. Basically, ALL SCC systems give the local user a > > local copy of what they need to develop. The difference though is that > > perforce has you check out BEFORE you start changing anything. The first > > advantage is that when someone else wants to edit that at the same time, > > perforce will warn them that you are already editing it. You can then chose > > to work at the same time, or wait for the other guy. When you check in, > > there is a nice GUI merge that let's you review your changes in the light of > > the other guys changes. > > > When you are happy you 'submit' and this sends the changes to the server, > > importantly, in an ACID transaction so that you get all the changes or none > > if something goes wrong. > > > When you are ready to release, you can either branch the code to a new > > directory named after the release number, or you can just label all the > > files so you can sync to the files as they were at that point in time. Disk > > is cheap so branching makes things easier to see. > > > Your best bet is to download the server and play with a copy of your code. > > You get 2 users or two workspaces for free. Tehre should be some good > > tutorials out there but the easiest way is to just email sales or support > > @perforce.com and ask them where to get started. They are really good at > > support :-) > > > Jim > > >> Can anybody clarify? > > >> Thanks in advance > > >> Simon > > >> -- > >> Please read the posting guidelines at: > >>http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > >> IMPORTANT: Type T24: at the start of the subject line for questions > > specific > >> to Globus/T24 > > >> To post, send email to [email protected] To unsubscribe, send email > >> to [email protected] > >> For more options, visit this group at > >>http://groups.google.com/group/jBASE?hl=en -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
