On 17 November 2010 03:03, jeffraro <jeffc_at_aspect.co.nz> wrote:
> This is my first exposure to tortoisesvn and I apologies for the "dumb
> question" in advance. I _have_ read the help and scanned the mailing
> list and can't find a direct answer to my question.
No worries, making your first strides in the realm of version control
can be intimidating. There are often multiple solutions to support
your preferred way of working and finding the one that best suits you
can take some time.
Fortunately, as long as you commit often it is difficult to really
lose a lot of work, so experimenting a bit should not be a problem.
> I am a single developer using Delphi.
> My project is at version 3.15 and I have a working copy in ...\MyApp
> I want to start working on v3.16 and continue to have 3.15 available
> so that I can fix bugs for the existing users and later carry these
> bug fixes forward into my 3.16 source.
There are two sides you need to think about: 1. the repository layout
and 2. your working copy/copies layout
Most important is the repository layout. If you are working on a
single product, you usually have one main development line. SVN
suggests you call this 'trunk'.
Whenever you are ready to release the product (say version x.y), you
create a 'stable branch' by copying the current trunk to
Development for the next version continues in trunk, bugfixing is done
on the branches/version x.y. If bugs are relevant on trunk as well,
you have several options: A. first fix on trunk and merge to the
branches/version x.y or B. fix on branches/version x.y and merge to
trunk or C. fix in both locations independently (if different fixes
are needed for example)
The versions that are actually released are usually 'tagged' by
creating another copy from the stable branch (or trunk) to
'tags/release x.y.z'.This tagged copy can then be used to actually
build the release (ensures stable code whenever the build has to be
Now as to working copy layout: you either have just one working copy
that you 'switch' between the different versions of your product
('trunk', 'branches/version x.y' or 'tags/release x.y.z'), or you
create multiple checkouts on your local disk, each pointing to one of
these locations. This greatly depends on the way you want to work and
may be dependent on the tooling you use (environment settings, file
locations that may be fixed etc.
Keep in mind that SVN is capable of merging changes from branch to
branch, as long as the lineage is known: SVN remembers the origin of
copies and uses that information to decide how changes made to these
origins can be merged into the copies at a later stage.
Once you have experimented a bit with this, read up on the concepts of
branching and merging. The SVN book has good info on this.
> Do I simply make a new WC in (say) ...\MyAppv3.16\Source and start
> working on my changes there?
That is possible, or continue in 'trunk' for version 3.16 after
creating a 'branches/version 3.15'.
> If so, I presume that I do my bug fixes 3.15 and "commit" them,
> then go to my 3.16 WC and "update".
No, you need to merge the fix on 3.15 into the working copy for 3.16.
Then review the merge and if it is OK, commit the change
> And not "commit" any 3.16 changes
> until I have finished working on that version?
Not true; on the 3.16 branch (or trunk) you should also commit all
3.16 changes, you do not want to lose intermediate work.
> OR do I use branches?
Yes, you should be using branches if you want to support multiple
versions of the product. Branches allow you to commit all of your work
frequently, reducing the risks of losing (intermediate) work.
 - svnbook.red-bean.com
. @@ // \\ "De Chelonian Mobile"
. (_,\/ \_/ \ TortoiseSVN
. \ \_/_\_/> The coolest Interface to (Sub)Version Control
. /_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-11-17 07:24:00 CET