David Valles wrote:
> I have been looking into using Subversion (namely
> TortoiseSVN) on several projects and groups of files
> that we have at work to track changes, diff versions,
> etc. and to replace our manual (i.e. file system)
> version control system.
>
> However, Subversion seems to be geared toward each
> developer having their own working copy and testing
> their changes on their own machines, but because of
> software license issues and the maintenance nightmare
> it would take to do that
I understand the license issues, but why would it be a maintenance
nightmare for each developer to have their own working copy of source
code? Subversion is designed for that kind of working practise - have
you look at
http://svnbook.red-bean.com/en/1.1/ch02s02.html#svn-ch-2-sect-2.3 (and
you will probably also want to read chapters 1 and 2 for an overview of
your options)
> we typically have a "test"
> system, which holds our test code and pending changes
> (with the appropriate licensed software), and a "live"
> system, which holds the live code.
We had something similar where I worked - there was one big beefy PC
that we'd do our builds on, which also had VMWare workstation on it,
where we'd test (rather than every developer having VMWare and the
hardware to be capable of running more than one VM at the same time).
We'd remote-desktop to it, check out the code we wanted to compile and
test, do that, and then log off when done. It was far from an ideal way
of working, but it worked for one person at a time.
> So, we only really
> have one "working copy." This single working copy
> problem is not likely to change.... What I need,
> though, is a workable, industry-standard version
> control system.
You will find http://software.ericsink.com/scm/source_control.html
useful, probably.
> Our current manual version control system is "copy the
> original into this folder here before you edit it" but
> I really want to get away from that.
>
> I noticed that TortoiseSVN can add a "Lock" column to
> Windows Explorer, and that could help multiple
> developers working in a "single" copy from trampling
> over each other, and the exclamation overlay icon also
> helps us to see pending changes, but commits might
> accidently put other programmer's code into
> production....
I've worked with the lock-modify-unlock scheme before and it drove me up
the wall. People would forget to unlock files, blocking my own work and
getting pissy when I kept asking to get at the files they were working
on. It was a slow system, and it absolutely relied on efficient
communication between the developers, ideally down to the level of
scheduling when each guy would work on each file. That's a complete
pain in the ass to do, so it didn't get done, and we thus had a
less-than-ideal system. Source control should be seamless and
transparent, not something that annoys people!
> Has anyone else had this problem, or could someone
> point me in the right direction?
Hopefully the links above will provide a bit more insight. I think
you're on to a loser, personally, by wanting to stick with one working
copy - the whole point of each guy having their own WC is so they can
make changes and let Subversion sort it out when they commit to the
repository.
Regards
Pete
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Sep 8 11:18:06 2005