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

RE: Tagging changesets

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-08-23 20:45:48 CEST

> -----Original Message-----
> From: John Doisneau [mailto:jdoisneau@gmail.com]
> Sent: Wednesday, August 23, 2006 1:02 PM
> 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.

        If you didn't have any version control, then how where you
tagging changeset?

>
> 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!
>

You made overlapping FunctionalityA and BugB changes to the same
file(s). (A + B + A changes.) So you're out of luck.

If you had done all the FunctionalityA work and committed, and then did
the BugB work and did a 2nd commit, then you would be able do a diff
each commit against the previous revision to get the A and B changesets.
(Or you could have done A work and comitted, then done B work and
committed, and finally finish the A work and committed.) Even so, this
isn't a realistic way to work, nor a reliable way to keep feature
changes separate.

If you want to segregate work streams, you need to use branches. The
SVN book covers basic branching (specifically feature branches.) You
may also want to look for a good Configuration Management (CM) book.
Ask around on www.cmcrossroads.com for advice.

*****

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 Wed Aug 23 20:48:09 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.