|
|
Seems like Perforce and other commercial products are absent from the poll.
|
|
|
|
|
We are a very small outfit of two. After losing directories of a solution while trying to use Visual SourceSafe but neglecting to specifically add every new subdirectory into it, and reading horror stories of how SourceSafe was adapted for Team Server, I simply zip the entire solution directory into a file, add the date and a letter onto it and sometimes a short description of the change, and copy it to our server and my development computer, both of which are backed up every day in different ways. I do this every time I make a programming change. Every once in a while, I clean out some intervening old versions to save disk space. This method is simple, reliable, easy to understand, no special tools required. Occasionally, I play with Git, because some code I am interested in is in GitHub, but as long as there is a learning or forgetting curve, I am not using it for production.
|
|
|
|
|
You really need to suck up the learning curve and use an actual source control solution. After the learning curve, you'll be glad you did. You'll realize that there are a lot of benefits to it other than just keeping a history of everything. Such as, being able to compare versions easily, being able to roll back changes, manage source branches, create tags for documentation (and long term supportability since you'll have the source code at any version easily accessible).
When I first started using SVN, it was a headache, but now.. I can't imagine what I'd do on a serious project without it.
|
|
|
|
|
None of that really matters.
|
|
|
|
|
That's obviously your opinion... Millions of source control users would likely beg to differ.
|
|
|
|
|
Albert Holguin wrote: Such as, being able to compare versions easily
You can do it with many other tools as well
Albert Holguin wrote: being able to roll back changes
Unzip other day and copy the function you want to roll back
Albert Holguin wrote: create tags for documentation
Correctly commented code needs not so much documentation
Albert Holguin wrote: long term supportability since you'll have the source code at any version easily accessible
Might be, but it is also easier to mess up that changing something in the configuration or making major editions, than with the other system.
Albert Holguin wrote:
That's obviously your opinion...
Exactly, as the other message was your opinion.
Albert Holguin wrote: Millions of source control users would likely beg to differ.
I have been always proud about not being part of the "major part". So that is not a valid argument for me. If all people jump from a bridge... would you jump as well?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I agree with you.
Quoting my own answer to other message above:
When I work on a project I am used to make at least 1 backup a day (there are days with several backups). The name of the backup is like:
ProjectName_BackupTimestamp_ChangesDescriptionSinceLastBackup(_Offline)
[/quote]
When I end the project and customer is happy with the result (what means certain stability in the code), then I clean up, leaving the 3 or 4 last important ones.
- Backups that are just a continuation of a previous day... deleted
- Backups that are full solutions but then specifications were changed or test functions being rejected by "I don't like it"... to a special folder, code can be useful for future projects. Changing name to something more descriptive of what is interesant inside it
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I use git primarily, but we're moving to TFS because we'd rather use the bronze medalist, I guess.
Sigh.
Anyway, since some of our stuff is in TFS and some hasn't converted yet, I use both of those.
|
|
|
|
|
...because all the projects I'm working on for my clients and personally in Ruby on Rails and hosted by Heroku use Git. 
Marc
|
|
|
|
|
sadly?
if you did not have your clients, which source control system would you use - if any?
|
|
|
|
|
Samuel Pearce wrote: which source control system would you use - if any?
I've used source control since the days of DOS, and for the last 5 years have been using SVN, which I still use for some personal projects, but most of my work, personal or for clients, now requires Git. Though, I believe Heroku supports SVN as well, but if I want to publish any gems for Ruby on Rails, I basically have to use GitHub.
Marc
|
|
|
|
|
Why there is no such category? 
|
|
|
|
|
Because they're marginal as you can see. I also use this marginal system - Hg.
|
|
|
|
|
"A narrowed down follow up "
|
|
|
|
|
Well... CVS sucks...   ...and well, it's not being developed anymore, and hasn't been for quite a while now (superseded by other options)...
...but Mercurial is widely popular, I'm surprised it's not on there...
|
|
|
|
|
I work for a big organization and not all our departments are using the same tool sets.
Internally we're using CVS but our external (visible to users external to the company) versioning system is subversion. We have different branches in different countries and even here there are differences. For my one project (working with users external to the country I live in but internal to the company) I'm working on we use rational ClearCase.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
|
I first started looking into source control a couple years ago, with my previous employer. Until then, I didn't have any projects of much complexity whatsoever, so I didn't feel the need for it. But once I began writing software for them, I knew it was time. I've been using Git since then, and I love it. 
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Matt U. wrote: I've been using Git since then, and I love it.
We're using Git, too. It's okay, but to love it you must be more than a little bit masochistic, mustn't you? 
|
|
|
|
|
ihoecken wrote: It's okay, but to love it you must be more than a little bit masochistic, mustn't you?
I must agree. I lead the switch from Perforce to Git in my group (the decision was made on a much higher level, though) but I don't think anybody is happy with it.
|
|
|
|
|
... what do you recommend for an upgrade path? I'm starting to look into this for us, as the day-to-day management of SourceSafe data bases is getting to be a PITA.
Team Foundation Server is an obvious first choice. We use SourceSafe sharing a lot, which TFS does not appear to support. How do you handle common source files (for example, .h files for libraries)?
I've also looked a little at SourceGear Vault, which recreates the SourceSafe environment but with a more sturdy SQL Server backend.
I'll probably also take a look at Subversion, given its popularity. I doubt I would consider Git, as we don't need distributed access, the learning curve sounds steep, and there's no Visual Studio integration.
Software Zen: delete this;
|
|
|
|
|
We are in the same boat; we have looked at various including TFS and Subversion.
TFS is far more than we need generally, but as well as sharing, it does not support keyword expansion either, which we use.
Subversion seems to have some serious limitations, particularly version labeling.
We are currently trying SourceAnyWhere, which again recreate SourceSafe with an SQL backend.
|
|
|
|
|
Having tried others including Bazar, which should be renamed to Bizarre, I settled on Subversion and have never regretted the decision.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
Subversion does do version labelling. Just create a branch at the point you want labelled.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
