Re: Tagging changesets

Considering I'm very new to Subversion as well (still evaluating it
for my workplace in fact) hopefully this understanding isn't too far
'out there'.

These are hopefully valid assumptions
- The Commit command accepts a 'list file' of paths to commit.
- Each commit is atomic and all changes are identifiable by the
resulting revision number
- You can list all changes made between a given revision number and
its predecessor.

If those are true then creating two 'list files' that respectively
include the modifications for each of the changes would allow you to
commit them separately with meaningful commit messages and then update
your issue tracker with the resulting revision numbers.

You can even paste the contents of the commit list to the issue
tracker as a record.

(on a separate note and clearly not one this list should be expected
to answer but...)
Why doesn't RapidSVN do exactly this to support atomic commits across
folders - since one of the big advantages of SVN is atomic commits
that seems a sensible approach.

--
Talden
On 8/24/06, John Doisneau <jdoisneau@gmail.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org