[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Thanks

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-08-21 23:24:15 CEST

> -----Original Message-----
> From: The Dan Keefer [mailto:dan_keefer@yahoo.com]
> Sent: Monday, August 21, 2006 4:46 PM
> To: Sub Version
> Subject: Thanks
>
>
> First, thanks go out to all the respondents.
>
> Yes, I am largely unfamiliar with source code management
> and version control software. I understand most of the
> issues, but I know that the powers to be aren't going to
> want (or be able) to completely change everything we do.
>
> Every developer has his own copy of CF, SQL Server, and
> code.
>
> Typically when we are asked to either develop or or fix
> something, we do it on our local copy. Each of us copies
> our changed/new files onto a development server and copies
> the changed code of others onto our local copies. We are
> to check the time stamp of each file as it it copied.
>
> We are well aware of the problems with this process, which
> is why we are looking into Subversion.
>
> However, not only do our copies need to run independently
> of the server, but the server is used for testing
> development by non-programmers so it is considered the
> latest development copy, though there are works in progress.

You are *this* close to enlightenment.

Here's your new process[1]:
a) Developers checkout to a local workspace.
b) They work and test in their local workspace.
c) They then commit their changes into Subversion
d) The Testers (or whoever is in charge of the server) says:
        "I want revision 150 of the code put onto the test server."
The Tester then types:
        svn update -r 150
The Tester then changes his mind and says:
        "I really meant that I wanted revision 145 of the code."
The Tester then types:
        svn update -r 145
The Tester tests.

Try this and see if it helps:
        create a test repository.
        Checkout the new repository 'svn co svn://server/new_repos
my_test'
        cd my_test
        create a new file with the word 'one'
        svn add file.txt
        svn commit file.txt
        Edit file.txt and add the word 'two'
        svn commit file.txt
        Edit the file.txt and add the word 'three'
        svn commit file.txt

        svn update
        cat file.txt (it will have 'one', 'two', and 'three')
        svn update -r 1
        cat file.txt (it will only have 'one')
        svn update -r 2
        cat file.txt (it will have 'one' and 'two')

Folks can check in code willy-nilly, but the testers can decide which
revision they want to test against.
        
>
> It SOUNDS like each time a file is changed, it goes into a
> new folder (potentially) so that the latest version isn't in
> the web site path anymore.

You don't have to do this. If people have checked in 200 times, you can
pick what revision (from 1 to 200) of the code you want. Version
control allows you segregate code by time. Stop trying to segregate
code by space (aka folders.) You use folders (aka branches) to segreate
by release or features.

[1] However this is not the best way to work. Instead developers
should probably test on a private (or feature) branch and merge the code
to trunk once it's been completed and tested. The testers then grab
code from the trunk and test it ("svn export -r 123
svn://server/repos/trunk" or "svn co -r 123 svn://server/repos/trunk")

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 21 23:28:07 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.