Introducing SVN, best practices for people that work together without any version control

[Jochen Wendebaum <jo...@wendebaum.de>]

Hi all,

we are introducing subversion in our development department (30ppl). Most  
of us have single projects and work alone which makes the introduction  
quite easy (well, more and more collaborative work is coming so it's the  
time now to get a system into the department). Some of the people work  
together already on a single project and share the sourcecode (by copying  
it!), everyone works on his files and every 6 weeks they do a manual merge  
(which takes half a day). So now we are in the situation that such a merge  
would have to take place, and at the same time we start with subversion.

My question is how to go on...

1. first do the manual merge and then introduce svn
2. install svn, do the merge with svn

If we do the merge with svn, how shall we proceed? Put both version into  
the db, or only one, and then merge them on a local copy?

I am a bit clueless atm...

Thanks,

Jochen Wendebaum
jochen@wendebaum.de

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Introducing SVN, best practices for people that work together without any version control

[Tom Mornini <tm...@infomania.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 31, 2005, at 11:25 PM, Jochen Wendebaum wrote:

> 1. first do the manual merge and then introduce svn
> 2. install svn, do the merge with svn
>
> If we do the merge with svn, how shall we proceed? Put both version 
> into the db, or only one, and then merge them on a local copy?

Ideal situation would be this:

Put some common ancestor (the last release code, or after the last 
merge) into the trunk. Make two branches, one for each developer,
check out the branches, and overlay the current code from each 
developer into their branch, then commit.

Now the merges will have a common ancestor, which should make for 
cleaner merges (3 way rather than 2 way), and the change history will
be complete.

- -- 
- -- Tom Mornini

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB/8bvzaKkuvKwKvcRAmWZAJ9fSYHGYOPumWd5KVlePu3Elh2M/gCdFLY0
iQ8RI6WnhdoQHpTl5ntM+Ac=
=cbHR
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Introducing SVN, best practices for people that work together without any version control

[Dale Worley <dw...@pingtel.com>]

-----Original Message-----
From: Jochen Wendebaum [mailto:jochen@wendebaum.de]

1. first do the manual merge and then introduce svn
2. install svn, do the merge with svn
---------------------------------------------------------------------

It would take less work overall to do the manual merge, load it into Svn,
and then have everyone check out a new working copy.  But that's a big-bank
approach, which assumes you can take a few day's hit right now.

If you *needed* to be able to introduce Svn incrementally, you could start
by installing each person's code onto a separate branch of the project(s).
Then as each developer is brought into a fully shared Svn system, you merge
his code into the main, and he starts using a WC based on main.  Requires
more bookkeeping, but it wouldn't take very long to import a developer's
code base into a branch and check him out a WC of it.

Dale


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org