* Release tags @ 2012-08-28 16:48 chad 2012-08-29 2:40 ` Chong Yidong 0 siblings, 1 reply; 34+ messages in thread From: chad @ 2012-08-28 16:48 UTC (permalink / raw To: emacs-devel@gnu.org discussions Is there a tag I can use to identify the 24.2 release codebase? I see some EMACS_PRETEST_24_xxx tags and emacs-24.1, but nothing for 24.2. Thanks, *Chad ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-08-28 16:48 Release tags chad @ 2012-08-29 2:40 ` Chong Yidong 2012-09-04 0:40 ` Tim Cross 0 siblings, 1 reply; 34+ messages in thread From: Chong Yidong @ 2012-08-29 2:40 UTC (permalink / raw To: chad; +Cc: emacs-devel@gnu.org discussions chad <yandros@MIT.EDU> writes: > Is there a tag I can use to identify the 24.2 release codebase? > > I see some EMACS_PRETEST_24_xxx tags and emacs-24.1, but nothing > for 24.2. I forgot to make the tag. It should be there now (emacs-24.2). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-08-29 2:40 ` Chong Yidong @ 2012-09-04 0:40 ` Tim Cross 2012-09-04 2:25 ` Óscar Fuentes 2012-09-04 2:29 ` William Stevenson 0 siblings, 2 replies; 34+ messages in thread From: Tim Cross @ 2012-09-04 0:40 UTC (permalink / raw To: Chong Yidong; +Cc: chad, emacs-devel@gnu.org discussions I cannot see a tag for emacs-24.2. Updated today and see log messages for commits dated for 3 Sept, so I appear to be up-to-date. CAn see tag for emacs-24.1, but nothing for emacs 24.2. Is this in another branch? Tim On 29 August 2012 12:40, Chong Yidong <cyd@gnu.org> wrote: > chad <yandros@MIT.EDU> writes: > >> Is there a tag I can use to identify the 24.2 release codebase? >> >> I see some EMACS_PRETEST_24_xxx tags and emacs-24.1, but nothing >> for 24.2. > > I forgot to make the tag. It should be there now (emacs-24.2). > -- Tim Cross ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 0:40 ` Tim Cross @ 2012-09-04 2:25 ` Óscar Fuentes 2012-09-04 2:29 ` William Stevenson 1 sibling, 0 replies; 34+ messages in thread From: Óscar Fuentes @ 2012-09-04 2:25 UTC (permalink / raw To: emacs-devel [text reordered for clarity; please don't top-post] > On 29 August 2012 12:40, Chong Yidong <cyd@gnu.org> wrote: >> I forgot to make the tag. It should be there now (emacs-24.2). Tim Cross <theophilusx@gmail.com> writes: > I cannot see a tag for emacs-24.2. Updated today and see log messages > for commits dated for 3 Sept, so I appear to be up-to-date. CAn see > tag for emacs-24.1, but nothing for emacs 24.2. Is this in another > branch? I see the tag on the git mirror repo, so it must be on the bzr repo as well. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 0:40 ` Tim Cross 2012-09-04 2:25 ` Óscar Fuentes @ 2012-09-04 2:29 ` William Stevenson 2012-09-04 2:50 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: William Stevenson @ 2012-09-04 2:29 UTC (permalink / raw To: emacs-devel Tim Cross <theophilusx@gmail.com> writes: > I cannot see a tag for emacs-24.2. Updated today and see log messages > for commits dated for 3 Sept, so I appear to be up-to-date. CAn see > tag for emacs-24.1, but nothing for emacs 24.2. Is this in another > branch? I see one in branch emacs-24: emacs-24.2 108121 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 2:29 ` William Stevenson @ 2012-09-04 2:50 ` Eli Zaretskii 2012-09-04 14:32 ` Jason Rumney 2012-09-05 7:16 ` Glenn Morris 0 siblings, 2 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-04 2:50 UTC (permalink / raw To: William Stevenson; +Cc: emacs-devel > From: William Stevenson <yhvh2000@gmail.com> > Date: Tue, 04 Sep 2012 03:29:03 +0100 > > Tim Cross <theophilusx@gmail.com> writes: > > > I cannot see a tag for emacs-24.2. Updated today and see log messages > > for commits dated for 3 Sept, so I appear to be up-to-date. CAn see > > tag for emacs-24.1, but nothing for emacs 24.2. Is this in another > > branch? > > I see one in branch emacs-24: > emacs-24.2 108121 It should have been on the trunk as well, though, because: 109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124 Or maybe this will land upon the next merge from emacs-24. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 2:50 ` Eli Zaretskii @ 2012-09-04 14:32 ` Jason Rumney 2012-09-04 15:57 ` Óscar Fuentes 2012-09-04 16:53 ` Eli Zaretskii 2012-09-05 7:16 ` Glenn Morris 1 sibling, 2 replies; 34+ messages in thread From: Jason Rumney @ 2012-09-04 14:32 UTC (permalink / raw To: Eli Zaretskii; +Cc: William Stevenson, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > It should have been on the trunk as well, though, because: > > 109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124 > > Or maybe this will land upon the next merge from emacs-24. Tags are pulled in by a merge from another branch in bzr? Seems like a confusing misfeature to me if true. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 14:32 ` Jason Rumney @ 2012-09-04 15:57 ` Óscar Fuentes 2012-09-04 16:04 ` Jason Rumney 2012-09-04 16:57 ` Eli Zaretskii 2012-09-04 16:53 ` Eli Zaretskii 1 sibling, 2 replies; 34+ messages in thread From: Óscar Fuentes @ 2012-09-04 15:57 UTC (permalink / raw To: emacs-devel Jason Rumney <jasonr@gnu.org> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> It should have been on the trunk as well, though, because: >> >> 109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124 >> >> Or maybe this will land upon the next merge from emacs-24. > > Tags are pulled in by a merge from another branch in bzr? Seems > like a confusing misfeature to me if true. A tag is associated to a revision (actually, it is a name you give to a revision.) A revision can enter the history of any branch (via merge), therefore its associated tag(s) will appear on the logs of those branches. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 15:57 ` Óscar Fuentes @ 2012-09-04 16:04 ` Jason Rumney 2012-09-04 17:47 ` Andreas Schwab 2012-09-04 18:24 ` Óscar Fuentes 2012-09-04 16:57 ` Eli Zaretskii 1 sibling, 2 replies; 34+ messages in thread From: Jason Rumney @ 2012-09-04 16:04 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > A tag is associated to a revision (actually, it is a name you give to a > revision.) A revision can enter the history of any branch (via merge), > therefore its associated tag(s) will appear on the logs of those > branches. No use of a tag that I have ever seen was for a revision. It was for the state of the source tree at that point in time. Release tags especially. If there are multiple Emacs 24.2 tags in the repository, how is one supposed to know which is the real Emacs 24.2? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 16:04 ` Jason Rumney @ 2012-09-04 17:47 ` Andreas Schwab 2012-09-05 14:55 ` Jason Rumney 2012-09-04 18:24 ` Óscar Fuentes 1 sibling, 1 reply; 34+ messages in thread From: Andreas Schwab @ 2012-09-04 17:47 UTC (permalink / raw To: Jason Rumney; +Cc: Óscar Fuentes, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > No use of a tag that I have ever seen was for a revision. It was for the > state of the source tree at that point in time. A revision _is_ a state of the tree at one point in time. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 17:47 ` Andreas Schwab @ 2012-09-05 14:55 ` Jason Rumney 2012-09-05 15:18 ` Andreas Schwab 0 siblings, 1 reply; 34+ messages in thread From: Jason Rumney @ 2012-09-05 14:55 UTC (permalink / raw To: Andreas Schwab; +Cc: Óscar Fuentes, emacs-devel Andreas Schwab <schwab@linux-m68k.org> writes: > Jason Rumney <jasonr@gnu.org> writes: > >> No use of a tag that I have ever seen was for a revision. It was for the >> state of the source tree at that point in time. > > A revision _is_ a state of the tree at one point in time. Except when you merge that revision onto another branch, some here seemed to be saying the tag would be merged with it, which makes no sense to me, because after the merge what gets checked in should be a different revision (even though the patch from the previous revision to the new one is the same between branches, the content of the tree is different). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 14:55 ` Jason Rumney @ 2012-09-05 15:18 ` Andreas Schwab 2012-09-05 15:33 ` Óscar Fuentes 0 siblings, 1 reply; 34+ messages in thread From: Andreas Schwab @ 2012-09-05 15:18 UTC (permalink / raw To: Jason Rumney; +Cc: Óscar Fuentes, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > Except when you merge that revision onto another branch, some here > seemed to be saying the tag would be merged with it, which makes no > sense to me, because after the merge what gets checked in should be a > different revision No, the merged revisions don't change. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 15:18 ` Andreas Schwab @ 2012-09-05 15:33 ` Óscar Fuentes 2012-09-07 13:22 ` Jason Rumney 0 siblings, 1 reply; 34+ messages in thread From: Óscar Fuentes @ 2012-09-05 15:33 UTC (permalink / raw To: Andreas Schwab; +Cc: emacs-devel, Jason Rumney Andreas Schwab <schwab@linux-m68k.org> writes: > Jason Rumney <jasonr@gnu.org> writes: > >> Except when you merge that revision onto another branch, some here >> seemed to be saying the tag would be merged with it, which makes no >> sense to me, because after the merge what gets checked in should be a >> different revision > > No, the merged revisions don't change. Jason, try executing `bzr qlog' from your trunk branch checkout and click on the small circles that contains a + symbol (those are merge revisions.) You will see that a merge revision joins a series of revisions from the original branch (trunk, in this case) with a series of revisions coming from another branch. All revisions are there. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 15:33 ` Óscar Fuentes @ 2012-09-07 13:22 ` Jason Rumney 2012-09-07 14:35 ` Eli Zaretskii 2012-09-07 15:27 ` Stefan Monnier 0 siblings, 2 replies; 34+ messages in thread From: Jason Rumney @ 2012-09-07 13:22 UTC (permalink / raw To: Óscar Fuentes; +Cc: Andreas Schwab, emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Jason, try executing `bzr qlog' from your trunk branch checkout and > click on the small circles that contains a + symbol (those are merge > revisions.) You will see that a merge revision joins a series of > revisions from the original branch (trunk, in this case) with a series > of revisions coming from another branch. All revisions are there. bzr: ERROR: unknown command "qlog" I think what you are trying to explain is that bzr's history is full of confusing non-linear parallel universes. 24.2 never existed on the trunk as far as history of this universe goes - it was made on a branch. But DVCS adherents want the possibility of an alternate universe where 24.2 is on the history of the trunk. The benefit of this non-linearity is not at all clear to me. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-07 13:22 ` Jason Rumney @ 2012-09-07 14:35 ` Eli Zaretskii 2012-09-07 15:27 ` Stefan Monnier 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-07 14:35 UTC (permalink / raw To: Jason Rumney; +Cc: ofv, schwab, emacs-devel > From: Jason Rumney <jasonr@gnu.org> > Date: Fri, 07 Sep 2012 21:22:26 +0800 > Cc: Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org > > Óscar Fuentes <ofv@wanadoo.es> writes: > > > Jason, try executing `bzr qlog' from your trunk branch checkout and > > click on the small circles that contains a + symbol (those are merge > > revisions.) You will see that a merge revision joins a series of > > revisions from the original branch (trunk, in this case) with a series > > of revisions coming from another branch. All revisions are there. > > bzr: ERROR: unknown command "qlog" You most probably don't have the Qbzr plugin installed. > 24.2 never existed on the trunk as far as history of this universe > goes - it was made on a branch. I think you are mixing the tree and the version meta-data. All the versions on the branch "exist" on the trunk as well, in the sense that their history is in the trunk meta-data, and, if one wants, one can make the working tree of the trunk to be exactly as one of the branch revisions. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-07 13:22 ` Jason Rumney 2012-09-07 14:35 ` Eli Zaretskii @ 2012-09-07 15:27 ` Stefan Monnier 1 sibling, 0 replies; 34+ messages in thread From: Stefan Monnier @ 2012-09-07 15:27 UTC (permalink / raw To: Jason Rumney; +Cc: Óscar Fuentes, Andreas Schwab, emacs-devel > branch. But DVCS adherents want the possibility of an alternate > universe where 24.2 is on the history of the trunk. The benefit of this I think there's just a simple misunderstanding of what tags are. Bazaar's tags are just mapping from names to revids. They're stored in a branch because that seemed like a good idea. Bzr propagates it between branches whenever it gets a chance, pretty much. So the tags in a branch can refer to revids in different branches, some of which may have nothing to do whatsoever with the current branch. There can also be a tag that points to a revid that doesn't exist, or that existed but has been retracted, ... I think Bzr's tags were not very well though out (e.g. you can't remove a tag, because of how Bzr likes to eagerly and blindly spread them, which causes them to come right back unless you remove them from everywhere at the same time). But the important point is that they do not say anything reliable about the history of the current branch on which you find them. Stefan ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 16:04 ` Jason Rumney 2012-09-04 17:47 ` Andreas Schwab @ 2012-09-04 18:24 ` Óscar Fuentes 2012-09-04 22:43 ` Tim Cross 1 sibling, 1 reply; 34+ messages in thread From: Óscar Fuentes @ 2012-09-04 18:24 UTC (permalink / raw To: emacs-devel Jason Rumney <jasonr@gnu.org> writes: > No use of a tag that I have ever seen was for a revision. It was for the > state of the source tree at that point in time. Release tags especially. > > If there are multiple Emacs 24.2 tags in the repository, how is one > supposed to know which is the real Emacs 24.2? Any of them will do, because the revision (and hence the tag) determines the complete state of the source tree. Plus the complete VC history that precedes that revision. So if the emacs-24 branch were magically lost, it could be partially recovered (VC history included) from any other branch that contains a merged revision that comes from emacs-24. (Partially means "except the revisions committed after the emacs-24 revision you have at hand.") ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 18:24 ` Óscar Fuentes @ 2012-09-04 22:43 ` Tim Cross 2012-09-05 1:53 ` Stephen J. Turnbull 2012-09-05 2:34 ` Óscar Fuentes 0 siblings, 2 replies; 34+ messages in thread From: Tim Cross @ 2012-09-04 22:43 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel On 5 September 2012 04:24, Óscar Fuentes <ofv@wanadoo.es> wrote: > Jason Rumney <jasonr@gnu.org> writes: > >> No use of a tag that I have ever seen was for a revision. It was for the >> state of the source tree at that point in time. Release tags especially. >> >> If there are multiple Emacs 24.2 tags in the repository, how is one >> supposed to know which is the real Emacs 24.2? > > Any of them will do, because the revision (and hence the tag) determines > the complete state of the source tree. > > Plus the complete VC history that precedes that revision. So if the > emacs-24 branch were magically lost, it could be partially recovered (VC > history included) from any other branch that contains a merged revision > that comes from emacs-24. (Partially means "except the revisions > committed after the emacs-24 revision you have at hand.") > > Just to clarify and get things back on track. I cannot see any emacs-24.2 tag in the main trunk. I suspect (but don't know for sure) that this is because the tag was not made in the emacs-24 branch before it was merged back into trunk. I suspect that the next merge from the emacs-24 branch will bring the tag into trunk. I don't see any problem with that. The reason I wanted the tag is that most of the time I run off the head of the main trunk. However, sometimes, if the trunk has some instabiity which is causing me problems, it is useful to have a known 'good state' in the trunk which allows me to check it out in a convenient way. The tag provides that convenience - I don't have to look back through the revisions to work out which difficult to remember revison number corresponds to the last stable release version Obviously, I could just check out the emacs-24 branch. However, I was hoping to avoid having to either switch branches or have two separate working trees - I find it more convenient to just maintain one tree. An earlier post in this thread identifies the revision number where the emacs-24.2 version was merged back into the dev trunk, so I can achieve what I want using that revision number. The tag is a convenience, but not essential. Tim -- Tim Cross ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 22:43 ` Tim Cross @ 2012-09-05 1:53 ` Stephen J. Turnbull 2012-09-05 2:34 ` Óscar Fuentes 1 sibling, 0 replies; 34+ messages in thread From: Stephen J. Turnbull @ 2012-09-05 1:53 UTC (permalink / raw To: Tim Cross; +Cc: Óscar Fuentes, emacs-devel Tim Cross writes: [Please trim irrelevant stuff you didn't write.] > I cannot see any emacs-24.2 tag in the main trunk. I suspect (but > don't know for sure) that this is because the tag was not made in the > emacs-24 branch before it was merged back into trunk. Right. What could and IMO should be done (ie, I do it when I'm RM :-) is to tag the branch point. That is the last "known good" point on the trunk (given the Emacs release process). > Obviously, I could just check out the emacs-24 branch. However, I was > hoping to avoid having to either switch branches Why? You're doing essentially the same thing anyway if you check out a tag. It's not a branch switch, but you've got the wrong code base for making changes to. ("Wrong" in the sense that you run a risk of unnecessary conflicts when merging your changes.) I'll grant that the bzr implementation of this gives me hives, but from the user point of view a shared repo (efficient storage of revisions common to the branches of interest) plus a lightweight checkout gives you the same effect as colocated branches for this purpose, at the slight cost of setting up a shared repo and learning an extra command IIRC. > An earlier post in this thread identifies the revision number where > the emacs-24.2 version was merged back into the dev trunk, so I can > achieve what I want using that revision number. No, you can't, if "known good revision" is what you want. Any instability introduced *in the trunk* since emacs-24.2 branched from the trunk is still in the trunk. You do not get a "known good" revision. You only get fixes to emacs-24.2 since the branch, but these should be pretty small, and won't address "new" instability. Steve ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 22:43 ` Tim Cross 2012-09-05 1:53 ` Stephen J. Turnbull @ 2012-09-05 2:34 ` Óscar Fuentes 2012-09-05 3:07 ` Stephen J. Turnbull 2012-09-05 14:32 ` Stefan Monnier 1 sibling, 2 replies; 34+ messages in thread From: Óscar Fuentes @ 2012-09-05 2:34 UTC (permalink / raw To: Tim Cross; +Cc: Óscar Fuentes, emacs-devel Tim Cross <theophilusx@gmail.com> writes: [snip] > An earlier post in this thread identifies the revision number where > the emacs-24.2 version was merged back into the dev trunk, so I can > achieve what I want using that revision number. The tag is a > convenience, but not essential. If you know the revision that corresponds to the emacs-24.2 tag upstream, why don't you tag your private branch yourself? You can create tags in your private checkouts as you please, although I would not use a name that you know exists elsewhere, just in case. BTW, in this case you are not interested on the merge revision that incorporated the emacs-24 VC history intro `trunk', but on the revision that comes from the emacs-24 branch and was tagged as `emacs-24.2'. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 2:34 ` Óscar Fuentes @ 2012-09-05 3:07 ` Stephen J. Turnbull 2012-09-05 3:49 ` Óscar Fuentes 2012-09-05 16:21 ` Eli Zaretskii 2012-09-05 14:32 ` Stefan Monnier 1 sibling, 2 replies; 34+ messages in thread From: Stephen J. Turnbull @ 2012-09-05 3:07 UTC (permalink / raw To: Óscar Fuentes; +Cc: Tim Cross, emacs-devel Óscar Fuentes writes: > If you know the revision that corresponds to the emacs-24.2 tag > upstream, why don't you tag your private branch yourself? Because he doesn't have that revision to tag. If he did, he'd have the tag, too. So he would need to branch emacs-24.2, and he doesn't want to do that (I'm not sure why, so I asked, we'll see what he says). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 3:07 ` Stephen J. Turnbull @ 2012-09-05 3:49 ` Óscar Fuentes 2012-09-05 5:11 ` Stephen J. Turnbull 2012-09-05 16:23 ` Eli Zaretskii 2012-09-05 16:21 ` Eli Zaretskii 1 sibling, 2 replies; 34+ messages in thread From: Óscar Fuentes @ 2012-09-05 3:49 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: Tim Cross, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: > Óscar Fuentes writes: > > > If you know the revision that corresponds to the emacs-24.2 tag > > upstream, why don't you tag your private branch yourself? > > Because he doesn't have that revision to tag. If he did, he'd have > the tag, too. No, he says that he has an up-to-date checkout of `trunk', which necessarily contains the revision tagged as `emacs-24.2', because it was merged into `trunk' almost 2 weeks ago. He also mentions that he knows the revision number of the merge. His problem is that the tag (not the revision) is missing from his private repo. > So he would need to branch emacs-24.2, and he doesn't > want to do that (I'm not sure why, so I asked, we'll see what he > says). Dealing with multiple branches on bzr is a bit of an inconvenience, for several reasons. One of them is mentioned by the OP: you end having multiple working copies around, or having to learn and remember tricks for reusing the same working copy. As the OP plans to use the emacs-24.2 stable point only in the rare cases when `trunk' is in a unusable state, his reluctance is understandable. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 3:49 ` Óscar Fuentes @ 2012-09-05 5:11 ` Stephen J. Turnbull 2012-09-05 6:34 ` Jambunathan K ` (2 more replies) 2012-09-05 16:23 ` Eli Zaretskii 1 sibling, 3 replies; 34+ messages in thread From: Stephen J. Turnbull @ 2012-09-05 5:11 UTC (permalink / raw To: Óscar Fuentes; +Cc: Tim Cross, emacs-devel Óscar Fuentes writes: > No, he says that he has an up-to-date checkout of `trunk', which > necessarily contains the revision tagged as `emacs-24.2', because it was > merged into `trunk' almost 2 weeks ago. He also mentions that he knows > the revision number of the merge. His problem is that the tag (not the > revision) is missing from his private repo. Unless he's done something that someone as bzr-averse as he seems to be would be very unlikely to do (namely, "bzr tag --delete emacs-24.2"), that's not his problem, that's a bzr bug. Tags should be copied. If that tag actually was on trunk at the time of the OP, my bet is that for some reason his checkout wasn't actually up-to-date. Both user error and common bzr bugs can account for that situation easily, so I prefer that assumption. > Dealing with multiple branches on bzr is a bit of an inconvenience, for > several reasons. One of them is mentioned by the OP: you end having > multiple working copies around, or having to learn and remember tricks > for reusing the same working copy. They're not tricks, they're standard bzr workflow for anybody needing to use branches, which is pretty much everybody following trunk. It's not that hard to learn to use "bzr switch" in a lightweight checkout. Granted that that's suboptimal (at least to drinkers of git-flavored Kool-Aid), I'm still curious why he considers lightweight checkouts unacceptable (if he does). One good alternative for him (as you mentioned earlier) would be to tag his private copy every time he gets a usable build. I expect that would pollute upstream if he ever pushed, though. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 5:11 ` Stephen J. Turnbull @ 2012-09-05 6:34 ` Jambunathan K 2012-09-05 12:48 ` Tim Cross 2012-09-05 16:25 ` Eli Zaretskii 2 siblings, 0 replies; 34+ messages in thread From: Jambunathan K @ 2012-09-05 6:34 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: Óscar Fuentes, Tim Cross, emacs-devel I am not sure whether the OP is using git repo of Emacs. I remember using git fetch --tags origin to refresh tags. Cannot recollect the exact scenario when I had to do this. ,---- From git help fetch | -t, --tags | Most of the tags are fetched automatically as branch heads are | downloaded, but tags that do not point at objects reachable from | the branch heads that are being tracked will not be fetched by this | mechanism. This flag lets all tags and their associated objects be | downloaded. The default behavior for a remote may be specified with | the remote.<name>.tagopt setting. See git-config(1). `---- Just guessing here. -- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 5:11 ` Stephen J. Turnbull 2012-09-05 6:34 ` Jambunathan K @ 2012-09-05 12:48 ` Tim Cross 2012-09-05 16:25 ` Eli Zaretskii 2 siblings, 0 replies; 34+ messages in thread From: Tim Cross @ 2012-09-05 12:48 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: Óscar Fuentes, emacs-devel On 5 September 2012 15:11, Stephen J. Turnbull <stephen@xemacs.org> wrote: > Óscar Fuentes writes: > > > No, he says that he has an up-to-date checkout of `trunk', which > > necessarily contains the revision tagged as `emacs-24.2', because it was > > merged into `trunk' almost 2 weeks ago. He also mentions that he knows > > the revision number of the merge. His problem is that the tag (not the > > revision) is missing from his private repo. > The emacs-24.2 tag was definetly NOT there and as there were comits in the log with timestamps indicating they had occured on the day I was checking, I assume things were up-to-date. What I am gussing has occured is that the emacs-24.2 tag was not added to the emacs-24 branch *before* the merge into trunk and was added to the 24 branch after the merge. This would mean it would be in the emacs-24 branch but not in trunk. If the tag had been created prior to the merge, then I would expect it would show up in trunk? > Unless he's done something that someone as bzr-averse as he seems to > be would be very unlikely to do (namely, "bzr tag --delete emacs-24.2"), > that's not his problem, that's a bzr bug. Tags should be copied. > Don't believe I'm doing anything unusual - pretty standard stuff really. > If that tag actually was on trunk at the time of the OP, my bet is > that for some reason his checkout wasn't actually up-to-date. Both > user error and common bzr bugs can account for that situation easily, > so I prefer that assumption. > > > Dealing with multiple branches on bzr is a bit of an inconvenience, for > > several reasons. One of them is mentioned by the OP: you end having > > multiple working copies around, or having to learn and remember tricks > > for reusing the same working copy. > > They're not tricks, they're standard bzr workflow for anybody needing > to use branches, which is pretty much everybody following trunk. It's > not that hard to learn to use "bzr switch" in a lightweight checkout. > Granted that that's suboptimal (at least to drinkers of git-flavored > Kool-Aid), I'm still curious why he considers lightweight checkouts > unacceptable (if he does). > I find dealing with bzr more effort and somewhat more confusing than any other system I use. I can't explain why and I'm not pushing for a change in what is used for emacs - for whatever reason, I don't find bzr at all intuitive or natural. It is also used by only two projects I deal witih and consequently, does not get enough use for me to remember much more than the basics. I have to constantly go back to the manual to work out how to do something I did only a few weeks back. Unless/until I find more things I'm interested in using based around bzr, this is unlikely to change. > One good alternative for him (as you mentioned earlier) would be to > tag his private copy every time he gets a usable build. I expect that > would pollute upstream if he ever pushed, though. Not a great alterantive unfortunately. I've actually tried that approach a while back. The problem is in deciding when something is stable/good enough to tage as such. Too often I found I'd tagged something as supposedly stable and just a little while later, run into something that cripples usability. I do find tags useful sometimes for other forms of tracking, but not for identifying good stable versions (at least no more useful than using the commit log). After seeing Glenn's message, I updated and the emacs-24.2 tag is now there. thanks Glenn. I apologise for this causing as much noise and speculation as it did - it wasn't what I expected. Tim -- Tim Cross ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 5:11 ` Stephen J. Turnbull 2012-09-05 6:34 ` Jambunathan K 2012-09-05 12:48 ` Tim Cross @ 2012-09-05 16:25 ` Eli Zaretskii 2 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-05 16:25 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: ofv, theophilusx, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Wed, 05 Sep 2012 14:11:47 +0900 > Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org > > Óscar Fuentes writes: > > > No, he says that he has an up-to-date checkout of `trunk', which > > necessarily contains the revision tagged as `emacs-24.2', because it was > > merged into `trunk' almost 2 weeks ago. He also mentions that he knows > > the revision number of the merge. His problem is that the tag (not the > > revision) is missing from his private repo. > > Unless he's done something that someone as bzr-averse as he seems to > be would be very unlikely to do (namely, "bzr tag --delete emacs-24.2"), > that's not his problem, that's a bzr bug. Tags should be copied. "bzr tag --delete" will remove the tag only until the next "bzr up", because the tag will be merged again at that time. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 3:49 ` Óscar Fuentes 2012-09-05 5:11 ` Stephen J. Turnbull @ 2012-09-05 16:23 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-05 16:23 UTC (permalink / raw To: Óscar Fuentes; +Cc: stephen, theophilusx, emacs-devel > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Wed, 05 Sep 2012 05:49:24 +0200 > Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org > > Dealing with multiple branches on bzr is a bit of an inconvenience, for > several reasons. One of them is mentioned by the OP: you end having > multiple working copies around, or having to learn and remember tricks > for reusing the same working copy. With bzr 2.5, you _can_ use co-located branches. But I won't recommend that with Emacs, because the branch and the trunk diverged so much at this point that you'd need a full bootstrap every time you switch. Which just about eliminates the advantage of co-located branches. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 3:07 ` Stephen J. Turnbull 2012-09-05 3:49 ` Óscar Fuentes @ 2012-09-05 16:21 ` Eli Zaretskii 2012-09-05 17:32 ` Stephen J. Turnbull 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2012-09-05 16:21 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: ofv, theophilusx, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Wed, 05 Sep 2012 12:07:49 +0900 > Cc: Tim Cross <theophilusx@gmail.com>, emacs-devel@gnu.org > > Óscar Fuentes writes: > > > If you know the revision that corresponds to the emacs-24.2 tag > > upstream, why don't you tag your private branch yourself? > > Because he doesn't have that revision to tag. If he did, he'd have > the tag, too. Not true: the revision was merged to the trunk before the tag was set on the branch. So he does have the revision, but not the tag (or, rather, he did, since Glenn just merged again, and the tag landed on the trunk). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 16:21 ` Eli Zaretskii @ 2012-09-05 17:32 ` Stephen J. Turnbull 2012-09-05 17:42 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Stephen J. Turnbull @ 2012-09-05 17:32 UTC (permalink / raw To: Eli Zaretskii; +Cc: ofv, theophilusx, emacs-devel Eli Zaretskii writes: > Not true: the revision was merged to the trunk before the tag was set > on the branch. Oh. That shouldn't happen .... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 17:32 ` Stephen J. Turnbull @ 2012-09-05 17:42 ` Eli Zaretskii 0 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-05 17:42 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: ofv, theophilusx, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: ofv@wanadoo.es, > theophilusx@gmail.com, > emacs-devel@gnu.org > Date: Thu, 06 Sep 2012 02:32:48 +0900 > > Eli Zaretskii writes: > > > Not true: the revision was merged to the trunk before the tag was set > > on the branch. > > Oh. That shouldn't happen .... Evidently, it does. Probably related to how tags are implemented in bzr. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-05 2:34 ` Óscar Fuentes 2012-09-05 3:07 ` Stephen J. Turnbull @ 2012-09-05 14:32 ` Stefan Monnier 1 sibling, 0 replies; 34+ messages in thread From: Stefan Monnier @ 2012-09-05 14:32 UTC (permalink / raw To: Óscar Fuentes; +Cc: Tim Cross, emacs-devel > If you know the revision that corresponds to the emacs-24.2 tag > upstream, why don't you tag your private branch yourself? Here's an easier recipe: bzr merge .../emacs-24 bzr revert that should bring in all the tags from the emacs-24 branch, just like th next merge from emacs-24 will, but without you having to deal with resolving the conflicts. Stefan ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 15:57 ` Óscar Fuentes 2012-09-04 16:04 ` Jason Rumney @ 2012-09-04 16:57 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-04 16:57 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Tue, 04 Sep 2012 17:57:11 +0200 > > >> Or maybe this will land upon the next merge from emacs-24. > > > > Tags are pulled in by a merge from another branch in bzr? Seems > > like a confusing misfeature to me if true. > > A tag is associated to a revision (actually, it is a name you give to a > revision.) A revision can enter the history of any branch (via merge), > therefore its associated tag(s) will appear on the logs of those > branches. And citing from bzr docs (assuming you believe them ;-): Tags give human-meaningful names to revisions. Commands that take a -r (–revision) option can be given -rtag:X, where X is any previously created tag. Tags are stored in the branch. Tags are copied from one branch to another along when you branch, push, pull or merge. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 14:32 ` Jason Rumney 2012-09-04 15:57 ` Óscar Fuentes @ 2012-09-04 16:53 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2012-09-04 16:53 UTC (permalink / raw To: Jason Rumney; +Cc: yhvh2000, emacs-devel > From: Jason Rumney <jasonr@gnu.org> > Cc: William Stevenson <yhvh2000@gmail.com>, emacs-devel@gnu.org > Date: Tue, 04 Sep 2012 22:32:32 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > It should have been on the trunk as well, though, because: > > > > 109804: Glenn Morris 2012-08-28 [merge] Merge from emacs-24; up to r108124 > > > > Or maybe this will land upon the next merge from emacs-24. > > Tags are pulled in by a merge from another branch in bzr? I assumed so, but the truth is I don't know. I just see that the tag for 24.1 is present in both the branch and the trunk, so I assumed it got to the trunk via a merge. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Release tags 2012-09-04 2:50 ` Eli Zaretskii 2012-09-04 14:32 ` Jason Rumney @ 2012-09-05 7:16 ` Glenn Morris 1 sibling, 0 replies; 34+ messages in thread From: Glenn Morris @ 2012-09-05 7:16 UTC (permalink / raw To: emacs-devel Eli Zaretskii wrote: > Or maybe this will land upon the next merge from emacs-24. Right. I merged it just now in an effort to curtail all this speculation. bzr tags | grep -F 24.2 emacs-24.2 107781.1.340 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2012-09-07 15:27 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-28 16:48 Release tags chad 2012-08-29 2:40 ` Chong Yidong 2012-09-04 0:40 ` Tim Cross 2012-09-04 2:25 ` Óscar Fuentes 2012-09-04 2:29 ` William Stevenson 2012-09-04 2:50 ` Eli Zaretskii 2012-09-04 14:32 ` Jason Rumney 2012-09-04 15:57 ` Óscar Fuentes 2012-09-04 16:04 ` Jason Rumney 2012-09-04 17:47 ` Andreas Schwab 2012-09-05 14:55 ` Jason Rumney 2012-09-05 15:18 ` Andreas Schwab 2012-09-05 15:33 ` Óscar Fuentes 2012-09-07 13:22 ` Jason Rumney 2012-09-07 14:35 ` Eli Zaretskii 2012-09-07 15:27 ` Stefan Monnier 2012-09-04 18:24 ` Óscar Fuentes 2012-09-04 22:43 ` Tim Cross 2012-09-05 1:53 ` Stephen J. Turnbull 2012-09-05 2:34 ` Óscar Fuentes 2012-09-05 3:07 ` Stephen J. Turnbull 2012-09-05 3:49 ` Óscar Fuentes 2012-09-05 5:11 ` Stephen J. Turnbull 2012-09-05 6:34 ` Jambunathan K 2012-09-05 12:48 ` Tim Cross 2012-09-05 16:25 ` Eli Zaretskii 2012-09-05 16:23 ` Eli Zaretskii 2012-09-05 16:21 ` Eli Zaretskii 2012-09-05 17:32 ` Stephen J. Turnbull 2012-09-05 17:42 ` Eli Zaretskii 2012-09-05 14:32 ` Stefan Monnier 2012-09-04 16:57 ` Eli Zaretskii 2012-09-04 16:53 ` Eli Zaretskii 2012-09-05 7:16 ` Glenn Morris
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.