My opinion is that it depends on what your development environment is.

I hate merges, mainly because you go through the coding part, then you go through the re-coding part when you need to see if your code will work with the other persons' code, and whether both new changes, and regression will still work, which I think is a reasonable overhead.

We're a small team, all sitting next to each other, and for us exclusive locks work better because before you go to modify a file you can simply ask the person next to you if they have a file locked exclusively and ask why, and see if a merge will be easy enough afterwards, or whether they'll be finished with it in an hour or so.  Plus people only work on their development PC's at their desks, so if they are away we can just check on their box what they've done/haven't done.

Obviously you need to make sure there are no locks before the person goes away on holiday ;) - but if you're a larger team this system may be impractical.

But I would think a shared development server would be quite difficult.  If someone's developing some site-wide change, they could stop all the other developers who are trying to get to the development server to do work, which would be quite frustrating!

TRACEY, Darren wrote:
I would have thought that VSS would be a large backward step from CVS.
The underlying difference between the 2 is that VSS uses exclusive file
locks and CVS does not.
The C in CVS stands for concurrent. While VSS only allows one person to
check-out any one file at a time and everyone else just has to wait for them
to finish with it (or come back to work the next day, or come back from
their 2 month European vacation), CVS lets everyone have all the files, and
it manages the changes that are done to the files when they are checked back
in, and allows merging of any conflicting files.
I've worked in a VSS shop and was constantly hearing people complaining
about files they needed being checked out by someone who wasn't there and no
one knew if they were actually working on that file or not. Its nasty, and I
wouldn't want to work under it.

I would suggest that the order of sophistication in a version control system
went something like this:
.No version control
....VSS
................CVS
...................SVN

Personally, I can't see any advantage in a shared development server,
especially as the size of the development team starts getting bigger.
Component development becomes very hard under a VSS style Version control
system as well, in that only one person can make changes to any component at
any one time, even if they are working in entirely different areas of that
component.

Regards 

Darren Tracey
Systems Analyst
Web Applications, Web and Integration Services
p: + 61 7 3232 4091 (x64091)
f: + 61 7 3232 4744
e: [EMAIL PROTECTED]
l: Lvl 9, 388 Queen St Brisbane QLD 4000
m: Suncorp IPC IT040, GPO Box 1453, Brisbane QLD 4000

  
-----Original Message-----
From:	CFAussie [SMTP:[EMAIL PROTECTED]]
Sent:	Friday, 23 July 2004 8:42
To:	CFAussie Mailing List
Subject:	[cfaussie] CVS vs. VSS

Hi,

Geoff gave a talk at MXDU about decentralised development and the use of
CVS to obtain version control on code. I've been using CVS internally
for some time now, using a decentralised development process, and it has
worked quite well.

However, I can see benefits in moving to a Visual Source Safe
development environment, where we use a development server and
'centralised' development.

I have been struggling with the pros and cons for a while now.. Besides
cost, what do people see as the advantages/disadvantages of both models?

Darryl

---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
    


-----------------------------------------------------------------------------------
This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities ("Suncorp"). 

Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 1800 689 762 or at suncorp.com.au.

The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.

If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line.


---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

  
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to