Thanks Thorsten. While its true that I didn't technically lose code, it was probably in there somewhere. The loss was discovered weeks later and we have a lot of code. It would take days going over everything then we would have to *hope* we got everything. Some things would let us know if we missed them, others things may not. We could go days or weeks before we noticed we were losing data. Since we were a few weeks away from the next release I decided to put off updating production. Basically it would cost too much to possibly not get all the code sprinkled with a slim chance of data loss. So from a business perspective, the code was lost.
In reality we should've had code control a long time ago. I only got here a few years ago. And when I first got here I met extreme resistance about incorporating something like subversion. I finally got the green light, quite possibly because they didn't have to spend any money. Now I must learn to use it. :) Revisions are global is what I needed to know, thanks. John -----Original Message----- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Wednesday, September 12, 2012 2:39 PM To: users@subversion.apache.org Subject: Re: Problem with merging Guten Tag John Maher, am Mittwoch, 12. September 2012 um 19:39 schrieben Sie: > I started using subversion a while back and doing a merge I lost a bunch > of source code which prohibited me from updating production for weeks. Unless you didn't commit, you can't loose source code, that's what version control is all about. Even if you didn't commit Subversion would always try everything to preserve your current modifications, which may result in the conflicts you describe later. The easiest way to never ever loose anything it always commit before doing any changes to your working copy like merges and whatever goes wrong after a commit can be restored. > I now have a stable code base and wish to use subversion so I tried to > follow chapter 4, branching and merging. It failed. If you mean your later mentioned conflicts with "failed", this isn't exactly true, as a conflict is a normal operation and the merge may succeed. Conflicts only mean that there are changes which Subversion can't merge automatically safely and the user needs to do something to merge the changes. This is not the same as an error during the merge or else. > 1) I was on revision 4. I then branced it, made a change and it > jumped to revision 7. Why? Does the revision apply to all folders > under a repository? Yes, revisions are global, that's one of the fundamental concepts of Subversion and is normally considered as a major benefit over previous centralized version control like CVS. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.............030-2 1001-310 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
