RE: Tagging changesets

I have over 8000 (large) source files excluding the contents of the hidden .svn directories; over 34000 files including the hidden .svn directories. And that doesn't include the many object files and executables that may appear following a debug build and a release build.

I have been known to have three or more working copies of the trunk, not to mention further working copies of a branch.

Usually two is enough. I too use Beyond Compare, for example, to separate out bug fix changes from my development WC to a clean WC.

Disk space is cheap; it's almost certainly cheaper than an engineer's time.

If disk space really is a problem for you, then you might be able to have additional WCs just for the subtrees for the module that you're working on. But it would still be better to just buy some bigger disks.

As far as (2) is concerned, you will get some of that functionality "for free" using "svn blame". Code that is full of change comments soon becomes difficult to read.

Source control software, when it's good, and when properly used, is a real help, not a hindrance. You don't need to keep change comments in the code: they can go in an SVN commit comment. You don't need to keep old versions of code or even old files: SVN will keep them for you.

By the way, when you do find that you need to branch, be generous: branch your entire trunk, for example. Branching with SVN is so cheap that you might as well. If you later find that you need to change a module that you hadn't anticipated would need modification, well you already have its sources in your branch.

SVN is pretty powerful, and what it can't do "out of the box" is usually very simple to script.

Rob.

-----Original Message-----
From: John Doisneau [mailto:jdoisneau@gmail.com]
Sent: 24 August 2006 14:48
To: users@subversion.tigris.org
Subject: Re: Tagging changesets

Thank you all for your replies.

I guess that the "2 working copies" scheme is the way to go, but is
this really practical when the software project is really big? Our
software contains about 3000 files. What do you think about your
solution in this case?

To answer the question "How are we currently doing this today in my
company?", we are doing it using a very simple method:

1) Work on FunctionalityA and BugB in the order you want, switching
from one task to the other as you wish

2) Before "committing" our changes (it is not really a commit since
we are not using version control software but it is equivalent) we use
a "differencing" software like Beyond Compare: it shows all the
changes made for both tasks and allows in place editing - we then use
the in place editing feature to add a little tag written like a
comment like /* FCT_A */ or /* BUG_B*/ at each block of code which was
added or modified. And usually at the top of the file where the most
changes have been made we add a longer description of the feature,
like
/* FCT_A: Developer DDD - mm/dd/yy - Implemented functionality A */

Does that make sense? Does that bring more comments?
Thanks.

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

_____________________________________________________________________
This incoming message has been checked for all known viruses by the Messagelabs Scanning System, on behalf of Celoxica Ltd.

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.

This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 24 16:40:12 2006