Which Version of trac is This Fix In ?
joseph....@rrd.com
Hi Folks,
Does anyone know which version of trac this change might be implemented in ? (http://trac.edgewall.org/changeset/5856)
Best Regards,
Joe
________________________________________________________________________________________
Joseph H. Dayney | Contract Software Engineer | RR Donnelley
630W 1000N | Logan, UT 84321 | (: 435-755-4278 | È: 801-608-1052 | Ê: 435-755-4210 | *: joseph....@rrd.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Noah Kantrowitz
--Noah
joseph....@rrd.com wrote:
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Trac Users" group.
> To post to this group, send email to trac-...@googlegroups.com
> To unsubscribe from this group, send email to trac-users-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
>
joseph....@rrd.com
Thanks Noah!
Best Regards,
Joe
________________________________________________________________________________________
Joseph H. Dayney | Contract Software Engineer | RR Donnelley
630W 1000N | Logan, UT 84321 | (: 435-755-4278 | È: 801-608-1052 | Ê: 435-755-4210 | *: joseph....@rrd.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
| Noah Kantrowitz <kan...@rpi.edu>
Sent by: trac-...@googlegroups.com 10/02/2007 05:35 PM
|
|
Jeremy Mordkoff
He knew the changeset number. It should be simple to map a changeset number to a branch.
Now that I'm on the subject, how do you track where a changeset has been merged to?
I see that you can put changeset numbers in the trac wiki. Wouldn't it also make sense to track the changeset number in the DB, so that you could (for example) list all changesets that contributed towards a milestone? Does anyone require that every changeset have a wiki entry?
JLM
QA pro but new to svn and trac
-----Original Message-----
From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On Behalf Of Noah Kantrowitz
Sent: Tuesday, October 02, 2007 7:35 PM
To: trac-...@googlegroups.com
Subject: [Trac] Re: Which Version of trac is This Fix In ?
Given thats a Genshi template, its in 0.11dev.
--Noah
joseph....@rrd.com wrote:
> Hi Folks,
>
> Does anyone know which version of trac this change might be
> implemented in ? (http://trac.edgewall.org/changeset/5856)
>
>
> Best Regards,
>
> Joe
>
> ______________________________________________________________________
> __________________
>
Emmanuel Blot
out on your own) is used with the Trac project.
> He knew the changeset number. It should be simple to map a changeset number to a branch.
There are no branch for Trac 0.11, as Trac 0.11 has not been delivered
yet. The trunk contains the latest development version of Trac. Once
Trac 0.11 is released, a new Trac 0.11-stable branch will be created,
and official releases of Trac will be tagged from this branch.
The trunk will become the current dev. branch for the next release -
0.12 - as soon as Trac 0.11 is delivered.
> Now that I'm on the subject, how do you track where a changeset has been merged to?
Trac developers use svnmerge script to track merge back and forth from
developer/sandbox branches and the trunk.
> I see that you can put changeset numbers in the trac wiki. Wouldn't it also make sense to track the changeset number in the DB
Can you elaborate? Wiki is stored in the DB, SVN changesets are also
tracked in the DB.
> Does anyone require that every changeset have a wiki entry?
You can enforce rules with commit hook scripts for example. Trac does
not enforce any specific rule, it's up to the team to define and use
them.
> so that you could (for example) list all changesets that contributed towards a milestone?
YMMV. Are you referring to Trac in general or to trac.edgewall.org
(i.e. the Trac project) itself?
Cheers,
Manu
Peckham, David
----- Original Message -----
From: trac-...@googlegroups.com <trac-...@googlegroups.com>
To: trac-...@googlegroups.com <trac-...@googlegroups.com>
Sent: Wed Oct 03 08:33:02 2007
Subject: [Trac] Re: Which Version of trac is This Fix In ?
Jeremy Mordkoff
> > number to a branch.
> There are no branch for Trac 0.11, as Trac 0.11 has not been delivered
> yet. The trunk contains the latest development version of Trac. Once
> Trac 0.11 is released, a new Trac 0.11-stable branch will be created,
> and official releases of Trac will be tagged from this branch.
> The trunk will become the current dev. branch for the next release -
> 0.12 - as soon as Trac 0.11 is delivered.
Okay, I get it. In clearcase, 'main' (which is normally the equivalent
of svn's 'trunk') is also a branch, albeit a special one.
But still, is there not an easy way to determine that a changeset only
exists in the trunk and not in any branch? Is this a feature of svnmerge
(which I have yet to try).
JLM
Emmanuel Blot
> exists in the trunk and not in any branch? Is this a feature of svnmerge
> (which I have yet to try).
A revision number in subversion can be considered as an instant
snapshot of the whole repository, so one cannot think in term of
whether a revision "exist or not" in a branch. A revision may contain
changes that have occurred in one branch or another, but each revision
applies to the repository as a whole. Moreover, a branch is nothing
more than a path in Subversion (whereas they are distinct objects in
ClearCase)
You cannot map the ClearCase way to the Subversion way. They are based
on very different idioms. I think you'll get confused if you try.
You may want to read the excellent "subversion book", available from
http://svnbook.red-bean.com/ that explains the Subversion concepts far
better than I'm able to.
To answer your question, yes you can easily get the list of the files
that have been changed in a revision, and check whether one or more
files are stored inside of the branch you want to observe.
HTH,
Manu
Noah Kantrowitz
trunk at that time without looking. Its easy enough to check the
revision of the tag of the last release.
--Noah
Jeremy Mordkoff
only
> > exists in the trunk and not in any branch? Is this a feature of
svnmerge
> > (which I have yet to try).
> A revision number in subversion can be considered as an instant
> snapshot of the whole repository, so one cannot think in term of
> whether a revision "exist or not" in a branch. A revision may contain
> changes that have occurred in one branch or another, but each revision
> applies to the repository as a whole. Moreover, a branch is nothing
> more than a path in Subversion (whereas they are distinct objects in
> ClearCase)
I don't think I ever said or implied that I was looking for a revision.
I am trying to track a changeset. A changeset is made one place (branch)
and then merged to other places, no? And each merge and commit creates a
new revision.
Back to the original (hypothetical) problem. I determine that the bug
that my customer just reported is fixed in changeset 1234. How do I
determine what version to give him that has this fix? It may be fixed in
the trunk. It may be fixed in a branch. It may have been merged. How do
I determine this?
JLM
Gary Oberbrunner
> Back to the original (hypothetical) problem. I determine that the bug
> that my customer just reported is fixed in changeset 1234. How do I
> determine what version to give him that has this fix? It may be fixed in
> the trunk. It may be fixed in a branch. It may have been merged. How do
> I determine this?
This is the wrong mailing list to be discussing this; it's for Trac, not
Subversion. (Still, what you want to do is hard in Subversion. Read the red
book to learn more.)
--
Gary
Christian Boos
On Oct 3, 5:16 pm, "Jeremy Mordkoff" <j...@zazzletech.com> wrote:
> Why did Joe even have to ask? Is this a limitation of trac or svn?
>
> He knew the changeset number. It should be simple to map a changeset number to a branch.
It depends what you mean by "branch". Subversion has a very simple
concept of branch: you simply create a branch by copying a folder. But
not necessarily all folder copies are meant to be new "branches" of
development (there could be "tags", or have any other purpose).
So if you simply want to know to which "Subversion branch" a given
changeset belongs to, this is trivial: the changeset lists the paths
which are affected by the changes. You look at the toplevel parts of
those path. In the case of r5856, it was 'trunk', which is simply the
branch for the version currently being developed, so not yet released
by definition. That's only a convention, but most projects adhere to
it. For other changesets, that could have been 'branches/0.10-stable',
which then means the next stable minor version on the 0.10.x line
(here, the conventions are much more varied - this is the Trac
project's convention). The versions currently being developed can be
seen on the "Roadmap" page.
If instead you want to explicitly relate a particular changeset to a
given /version/ of the software (which was I think the real concern
here), then the Trac's way is to put into play /tickets/. Changesets
should usually correspond to well documented bug fixes or enhancement
requests, i.e. tickets. Tickets in turn are related to Milestones,
which are roughly equivalent to versions or releases.
In the changeset r5856 which you were referring to, the commit log
message mentions "Fixes #152."
That links to http://trac.edgewall.org/ticket/152 which in turn
mentions that its milestone is "0.11". This means that the
functionality described in this ticket will be part of Trac version
0.11.
Note also that if trac.edgewall.org itself would be using 0.11, the
"0.11" above would be a link to the milestone 0.11.
> Now that I'm on the subject, how do you track where a changeset has been merged to?
Subversion 1.5 will have changeset merge tracking, and we'll think
about supporting this information once it becomes available. But I
think this will not really help in this situation: the merge metadata
is attached to the changeset created as a result of the merge
operation, not to the "merged" changeset, which makes it difficult to
know where a given changeset has been merged to. For more
informations, see:
http://subversion.tigris.org/merge-tracking/func-spec.html#find-changeset
> I see that you can put changeset numbers in the trac wiki. Wouldn't it also make sense to track the changeset number in the DB, so that you could (for example) list all changesets that contributed towards a milestone? Does anyone require that every changeset have a wiki entry?
You might be interested to look at #508 and more generally at
TracCrossReferences. The long term idea is to keep track of the formal
and informal relations between any kind of trac resources and then be
able to easily query those relations.
-- Christian