RE: Tagging changesets

John,

As far as I can see, you don't need either tags or branches.

Branches are required if
        * some changes are experimental
        * the two sets of changes are to appear in separate releases of the product

So, assuming that both FunctionalityA and BugB are both to appear in the next release of your product...

If you have worked on FunctionalityA and BugB, and they share files in common, then I imagine that those two tasks were undertaken in separate working copies (WCs). That would certainly be a sensible way to proceed.

So, let's suppose that your two WCs are located at /WC_A/ (which might be C:\WC_A\ on Windows, or something like /home/john/wc_a/ on Linux) and /WC_B/ on your PC, respectively.

Upon completing your tasks, /WC_A/ will contain changes to File1, File5 and File102; /WC_B/ will contain changes to File1 and File102 and I'll add FileX to that list.

Both WCs understand the 'BASE' from which you started, that is the revision in the repository corresponding to your working copy. (In the simplest case, this will be the same for all files.) In either WC, you can use the command "svn diff" to see the delta, i.e. the changes from the base, associated with its respective task.

Hopefully, before you started your tasks, your WCs were up to date (using svn update). If no-one else has made changes to those files, then at this point EITHER of your WCs are ready to be committed; otherwise an "svn update" might be necessary. To determine whether an update is necessary, you can use the command "svn status --show-updates" (or just "svn st -u").

So let us suppose that you decide to commit the bug fix first. Are you up to date?

        $ cd /WC_B/
        $ svn st -u
        M project/File1
        M project/File102
        M project/FileX

I'm simplifying the output here and below. Here, you will see other details, and you might see changes to other files by other engineers. The output here is showing you that there are no changes in the repository that you don't have: there are no *'s. So you commit:

        $ svn commit -m"Fixed bug B"
        Committed revision 123.

Note that because commits are atomic with SVN, all your changes for bug fix B are tied together in the new single revision 123. Later, you can query SVN for which files changed and even what the changes were for the fix to bug B.

Now you wish to commit your new feature from /WC_A/:

        $ cd ../WC_A/
        $ svn diff
        # ... shows you your changes for functionality A ...
        $ svn st -u
        M * project/File1
        M project/File5
        M * project/File102
               * project/FileX

Now you can see that /WC_A/ is no longer up to date. There are changes to both File1 and File102 locally in the WC ("M") and in the repository ("*"). So you must update.

        $ svn up
        G File1
        G File102
        U FileX
        Updated to revision 123.

This time you were lucky: SVN has merged your changes successfully ("G"). If those G's were C's, you would have had to resolve some conflicts (which is usually a straightforward exercise if you tend to keep your WCs up to date).

        $ svn st -u
        M project/File1
        M project/File5
        M project/File102
        $ svn diff
        # ... STILL shows you your changes for functionality A ...

In particular, your BASE in this WC has moved from, say revision 122, to revision 123. Thus the WC still understands the delta to do with the new functionality but NOT the bug fix.

Now you can check and test your combined changes, and then commit.

        $ svn commit -m"Implemented A"
        Committed revision 124.

Here, note that just the changes to implement functionality A as bound together in revision 124.

That's it.

In effect you have behaved like two engineers: one working on Bug B, and one working on functionality A. The problems are the same whether or not both engineers happen to be you.

Just because you're one engineer with one repository does not mean that you can have only one working copy. You can have WCs from different branches or directories in the repository. You can even have multiple WCs for any given branch or directory in the repository.

When I'm working on a new feature, but find a bug that I'd like to fix, I do exactly this. At other times, I find that I have inadvertently made two separate sets of changes in the same working copy. I tend to then (manually) split them into separate WCs and test and commit them separately as above. If such separate changes do not have files in common, it is also possible to commit them separately from the same WC by explicitly specifying the list of files on the "svn commit..." command.

I strongly recommend that you ensure that everyone on your team using SVN has read and understood the chapter on the basic work cycle <http://svnbook.red-bean.com/en/1.2/svn.tour.cycle.html>; the rest of the tour <http://svnbook.red-bean.com/en/1.2/svn.tour.html> is also very informative. For more details about the various svn "subcommands", such as "diff", "status", "update", "commit", see the reference section on "SVN Subcommands" <http://svnbook.red-bean.com/en/1.2/svn.ref.html>.

I hope this helps.

Rob.

-----Original Message-----
From: John Doisneau [mailto:jdoisneau@gmail.com]
Sent: 23 August 2006 18:02
To: users@subversion.tigris.org
Subject: Tagging changesets

Hello

I have a question that I have been wanting for quite a long time - I
hope I will write it clearly enough.

In our company, we are eager to switch to SubVersion (we did not have
any version control until now) but there could be one functionality
that we would lose if it is not supported: the possibility of tagging
changesets.

By "changeset" I mean a set of changes made in various files of the
software project all relative to the same evolution or correction.

Let's consider the following situation: today I worked out the 2
following changesets:
- To implement FunctionalityA, I had to change (or add) code in files
File1, File5 and File102
- To correct BugB (which is in no way related to FunctionalityA except
it shares some of its files), I had to modify File1 and File102

Let's say that I organized my day such that I worked the first couple
hours of the day on FunctionalityA, then I switched to BugB until the
middle of the afternoon, and then I went back to FunctionalityA, such
that at the end of the day I have completed those 2 tasks - ie my
changesets are ready to be commited to the SVN repository.

Now I would like to commit my code in such a way that it is possible
later for somebody to quickly see and take all the changes made to
implement FunctionalityA, and separately to correct BugB. How do I
perform this commit action?

If the changesets were not having some files in common, I could easily
commit in two steps:
1) commit the files of FunctionalityA
2) commit the files of BugB

Now you see that my problem is that the two changesets have some files
in common, so what can I do there? I cannot select part of a file and
commit just that part under TAG_FCT_A or TAG_BUG_B.

Would somebody have a suggestion to keep our organization in separate
changesets?

Thanks in advance!

---------------------------------------------------------------------
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 11:25:02 2006