Re: Tagging changesets

Then I guess you do need to do the work on a branch and once final and
committed merge back to trunk, delete branch, commit and record that
revision number as the changeset - certainly adds some 'noise' to the
log.

It means dealing with merging, which, if a once off is fine, if not it
seems the best option is playing with a .py script. I'm guessing that
merge-tracking is a way off given it's dependant upon an atomic move
operation amongst many other complicated tasks.

--
Talden
On 8/24/06, Gavin Lambert <gavinl@compacsort.com> wrote:
> Quoth Talden <mailto:talden@gmail.com>:
> > 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.
>
> Only if there are no overlapping files in those two lists.  If there's
> an overlap then the first commit will commit all changes to the file,
> since it's impossible to separate them at that point (unless they've
> been developed in isolation, on separate branches).
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org