[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: Talden <talden_at_gmail.com>
Date: 2006-08-24 07:51:48 CEST

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

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.

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
Received on Thu Aug 24 07:52:49 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.