RE: Subversion Beginner - General Overview - Multiple Users

I really like the editor analogy. I may use that in future.
 
There is one problem with the analogy. When editing a file in an editor, you save frequently, and save partially finished changes. But when committing a set of files to the repository, you should really only do so when the sources are in some good state (they compile, or pass the tests, or whatever).
 
Bob mentioned backup.
 
A source control system is not a backup system and should not be used as one. A change set should be complete. (Conversely, it is helpful also to keep them minimal, in the sense that a change set should be for a single feature or fix.)
 
You should, of course, backup. You should backup your local changes (but to a home area on a server or tape or CD, not to the repository).
 
The repository should also be backed up. That's very important. Your working copy may contain days' work, whereas your repository can contain years' work. For example, you might do a weekly "hot copy", and also backup that copy to tape. With SVN you can also "dump" individual commits, and have those dump files backed up, perhaps nightly.
 
If you commit bad (non-compiling, or whatever) change sets to the repository, it can be very difficult to analyse a development history later. Furthermore, you stop other engineers from being able to work effectively on those sources.
 
So, source control and backup are two important things, but they are not the same.
 
I think someone else has already mentioned this, but it's worth mentioning again anyway: source control is for "sources". You would usually put all the files that are required to build a product under source control, but not files generated by the build process. (For third-party tools and sources, it is not so clear what should be done, and there are different schools of thought. Clearly MSDEV itself and the MS C++ compiler don't go in the repository. But if you use something like the GMP number library or ZipStream, you might have it under source control if you customise it.) So, for example, you would have C/C++ source and header files (*.c, *.cpp, *.h or variants) under source control, as well as workspace ("solution" in Microsoft's daft terminology) and project files (*.sln, *.vcproj). The workspace and project files are generated in a sense, but they are also sources that are edited indirectly through the development environment, and they contain project file lists and dependencies, compilation options, and so on. But the compiled objects and executables should not be source controlled (*.obj, *.lib, *.exe, *.dll, and many others). In theory, these are reproducible from the sources that are under source control. (In practice, there may be binary differences due to time-stamping, for example.) The rule of thumb is: put under source control the minimum set of source files that enable the product to be built from a fresh checkout.
 
I hope these comments are helpful.
[And I hope they're not stupid answers.]
 
For a good introduction of how to use SVN in practice, read for example about the "Basic Work Cycle" <http://svnbook.red-bean.com/en/1.2/svn.tour.cycle.html>.
 
Rob.
 

-----Original Message-----
From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
Sent: 06 September 2006 19:02
To: users@subversion.tigris.org
Subject: RE: Subversion Beginner - General Overview - Multiple Users

In simple terms you can think of any repository as a file on your PC.
If you open that file and modify it, but NOT save the changes, your
modifications are NOT written to the file, but rather just on a buffer
used by your favorite editor correct? That's why if you open the same
file for a second time, while the first editor session is still open, you
don't see the changes. Now if you save your changes on the first
session and then subsequently open the same file, you will see your
changes correct?
 
You can think of your local copy (check out copy) as your editor
buffer, and a Subversion (or any other repository manager) repository
as the file. You can keep on working on your local copy. Others will
NOT see your changes 'til you "commit" them to the repository, nor
will you see others' changes 'til they commit to the repository.
 
Clear as mud?
 

  _____

From: Bob Butterworth [mailto:BButterworth@techpro.com]
Sent: Wednesday, September 06, 2006 1:33 PM
To: users@subversion.tigris.org
Subject: Subversion Beginner - General Overview - Multiple Users

Hi Everyone. I've been a programmer for a while now and I've recently needed at an increasing rate version control on my projects. After some research i've decided on Subversion. But I have a few general questions about the whole thing.
 
Currently have I have a .net project on my local computer, and that is where it stays. No one else can work on it but me, and occasionally I back it up.
 
If I set up a subversion server were multiple developers are accessing it for their projects, including me, how exactly does this work?
 
If I have the whole project with code on the server, does it get copied down to my local computer when I check it out. I can then work on it, and check back in the whole project? Does it then copy back up any changed files?
 
Do I keep my local copy of the project or do I always download everything from the server.
 
These may sound like stupid questions but i'm just trying to grasp how this works. Thanks for all your help
 
Bob
 

Bob Butterworth
        

Director of Web Development
 <mailto:bbutterworth@techpro.com> bbutterworth@techpro.com
        
----------------------------------------------------------

 <http://www.techpro.com/> Direct Line: 630 .938 .5306
Direct Fax: 630 .845 .4606
Toll Free: 800 .262 .0537 ext.106
318 Anderson Boulevard
Geneva, IL 60134

----------------------------------------------------------

w w w . t e c h p r o . c <http://www.techpro.com/> o m
        

TechPro E-Mail Disclaimer
The information contained in this e-mail and any accompanying documents is confidential, may be privileged, and is intended solely for the person and/or entity to whom it is addressed (i.e. those identified in the "To" and "Cc" box). They are the property of TechPro, Inc. Unauthorized review, use, disclosure, or copying of this communication, or any part thereof, is strictly prohibited and may be unlawful. If you have received this e-mail in error, please return the e-mail and attachments to the sender and delete the e-mail and attachments and any copy from your system. TechPro, Inc. Thank you for your cooperation.
 

_____________________________________________________________________
This incoming message has been checked for all known viruses by the Messagelabs Scanning System, on behalf of Celoxica Ltd.

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.

This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.