On Jun 8, 2006, at 14:15, Guillaume Bilodeau wrote:
> I have inherited a project that I will manage using Subversion.
> The repository doesn't exist yet and will need to be setup. I have
> two code bases: one for v1.0, which was already shipped, and a
> second for ongoing v2.0 development, which is not yet finished.
> Some substantial improvements will need to be integrated into a new
> v1.1 version and, when completed, ported to v2.0.
>
> I am completely new to Subversion and I've never been on the
> management side of SCM, always a user, so I don't know how to setup
> the repository and manage this development scenario. How should I
> go about doing this? Right now I'm leaning towards the following
> procedure:
>
> 1- install Subversion server on remote server
> 2- create the SVN repository
> 3- create main local directory (for source files)
> 4- copy all v1.0 files into main local directory
> 5- import the main local directory in the repo trunk
> 6- create a v1.0 tag from the repo trunk
> 7- create a v1.1 branch from the v1.0 tag
> 8- delete all files and directories in the main local directory
> (including .svn directories)
> 9- copy all v2.0 files to main local directory
> 10- commit to repo trunk
> 11- create a v2.0 tag from the repo trunk
> 12- develop v1.1 using the v1.1 branch
> 13- when v1.1 development is complete, create a v1.1 tag from the
> v1.1 branch
> 14- merge v1.1 branch into trunk
> 15- delete v1.1 branch
>
> Does this make any sense?
It's making some sense, yes. :-) I'd revise this a little, as follows.
When I had to load the initial versions of a project into Subversion
(they were also developed before we started using version control) I
used the svn_load_dirs.pl script. In your case you'd only have to use
it once, but even that can be helpful. Assuming you're using a single
repository for multiple projects, the strategy would be:
1. Install Subversion on server and client
2. Create repository
3. Set up empty directory structure for this project in the repository:
repository/
project/
trunk/
branches/
tags/
4. Check out the trunk.
5. Copy your v1.0 files into the checked-out trunk directory.
6. Use "svn add" to add all the files (except any you don't want to
check in), and commit.
(You could also use "svn import" instead of steps 3 thru 6, but I
always have trouble getting the syntax right and end up importing
things in the wrong place. And this way also enables you to exclude
some files from being added, if you want to do that.)
Now version 1.0 is in the repository trunk.
7. Copy the trunk to branches/1.1
8. Copy the trunk to tags/1.0
9. Use svn_load_dirs.pl to load a separate copy of your 2.0 code into
the repository and tag it as 2.0; something like:
svn_load_dirs.pl \
-t tags/2.0 \
$REPO/project \
trunk \
/local/path/to/project-2.0-src
svn_load_dirs.pl is an interactive CLI program which will try to do
all the necessary moves and renames to turn version 1.0 of your
project into version 2.0. If it finds files where it doesn't know
whether they're related, it'll prompt you. If, for example, version
1.0 contained a file foo.php and version 2.0 now contains bar/baz.php
it'll list the one on the left and the other on the right and you can
tell it that yes, the one is the ancestor of the other, and had you
been using Subversion at the time, you would have renamed them with
an svn mv. OTOH, if it shows you two files which truly aren't related
-- the one was deleted, and the other was created independently --
then you do nothing special, and let svn_load_dirs.pl handle it as a
normal delete of the one and an add of the other.
Now version 2.0 is in the repository trunk, and it has been tagged as
2.0.
10. Now you can develop version 1.1 on the 1.1 branch, and version
2.0 on the trunk, and tag them independently as you like, and merge
changes from the one to the other as you like.
There's no need to delete the 1.1 branch when you're done with it.
That wouldn't remove it from the repository, after all, so there's no
space savings. The only thing it does is remove the 1.1 branch from
the branches directory listing of the HEAD of the repository --
making it that much harder to take a look at it later when something
comes up. In some of our projects, we've created a directory "old"
inside branches, and moved old branches in there, so that people know
they're old (and they'll get an error message if they still have a
working copy of the branch at its original URL -- which reminds them
to upgrade to the current branch) but they're still easily accessible
if anybody does need to look into them again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 8 15:13:25 2006