RE: RE: Subversion Beginner - General Overview - Multiple Users
Date: 2006-09-07 15:14:43 CEST
The analogy ends with the understanding of
buffer/file->sandbox/repository.
________________________________
From: Rob Hubbard [mailto:Rob.Hubbard@celoxica.com]
Sent: Thursday, September 07, 2006 6:43 AM
To: users@subversion.tigris.org
Subject: 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
bbutterworth@techpro.com <mailto: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 o m <http://www.techpro.com/>
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.
