0000730: Mercurial revisions go out of sync

(0002934)
Torr Samaho (administrator)
2012-03-28 00:36

I agree that the revision number is fragile and that it's probably a good idea to move away from it, but how can it go out of sync in a clean clone?

(0002935)
Blzut3 (administrator)
2012-03-28 00:40

So you build from a clean clone as well? All I can tell you is if I build the tip I get the following: "src/svnrevision.h updated to revision 3414." The clone was done just a few minutes ago (using https), but just to be sure I ran hg pull and hg up -r tip.

(0002939)
Torr Samaho (administrator)
2012-03-28 01:41

> So you build from a clean clone as well?

No, but my clone should be identical to the bitbucket repo. To confirm this I just made a clean clone and "hg identify -n" returns the same number for the clean one and the one that I use to build the binaries. Which hg version are you using? I'm using 2.1.1. (actually tortoisehg-2.3.1).

(0002947)
Blzut3 (administrator)
2012-03-28 02:01
edited on: 2012-03-28 02:11

Hmm, interesting. I pulled your latest changes and it said it updated to 3416. Then when I went to modify updaterevision.c for debug purposes it fixed itself and now reads the revision correctly. I have no idea what caused that to happen. But in any case I'm uploading a new build now. I'll check the OS X build once that's done.

Regardless, it seems this needs to be changed sooner rather than later.

Edit: The Mac OS X build was showing the wrong, lower number as well. Same procedure fixed it, didn't even touch hg.

(0002949)
Blzut3 (administrator)
2012-03-28 02:20

Added some information no how you would go about getting the information from Mercurial, don't really have time to personally fix updaterevision since I need to work on term projects for school.

(0002960)
Torr Samaho (administrator)
2012-03-28 11:51

That looks promising. I'll look into it.

(0002981)
Torr Samaho (administrator)
2012-03-29 02:24

I started to investigate this and think using 'hg log -r. --template "{date|hgdate}"' and running the first number this command returns through the localtime command will do the trick (I want to create a single number based in the date in the format YYYYMMDDHHMM). More on this when I have more time, hopefully tomorrow.

(0002983)
Blzut3 (administrator)
2012-03-29 03:13

Storing the changeset hash as well would probably be a good idea. It would help verify the exact changeset used for those who care. (Particularly me since it might take awhile for me to get the Mac and 64-bit builds up depending on where I'm located when you do a release.)

(0003032)
Torr Samaho (administrator)
2012-03-30 02:13

I finished a first implementation using the YYYYMMDDHHMM approach for the version string and using the hgdate number as version number. It's not very likely that two commits are made during the same minute the revision an official beta build uses. Do you still think we need the changeset hash? And if so, where should it be displayed?

(0003035)
Blzut3 (administrator)
2012-03-30 02:23

I think the changeset hash would be much more convenient than looking through the logs for a commit that matches a given date (unless there's a good way to find it that I'm not aware of). I'm guessing you don't want to clutter the console with information most users don't care about, so I would suggest adding a "changeset" command or something that displays the changeset hash. (I would of course suggest also posting the changeset hash when you announce the builds.)

I would also suggest only using YYYYMMDD for the normally visible version number as it's unlikely that we'd produce two beta builds in the same day. It'd be less cluttered in appearance at least. The HHMM could be saved for the changeset command as well.

(0003051)
Torr Samaho (administrator)
2012-03-31 13:42

A "changeset" command (possibly "version_info" is a little more self explanatory name) is a good idea.

> I would also suggest only using YYYYMMDD for the normally visible version number as it's unlikely that we'd produce two beta builds in the same day.

That's certainly true for the official beta builds. I often release several unofficial beta builds during one day though, this would make it harder to distinguish those. We can also (additionally) shorten the year to YY (or even just Y).

(0003067)
Torr Samaho (administrator)
2012-03-31 17:45

I added the "version_info" command.

(0003069)
Blzut3 (administrator)
2012-03-31 18:01

That works for me. I imagine you're not going to use the underscores in the package file names (SkullDev98e-20120331platform[-arch].[ext])? Just wondering if I need to change anything on skulltag.net.

I guess one other thing I worry about is how the version is reported in the query protocol. Right now Doomseeker will try to download "r2012_03_31 17:44" and accordingly try to put that into the SkullDev file name.

(0003070)
Torr Samaho (administrator)
2012-03-31 18:18

I hope we can continue to use the same version string in the filenames and in the game itself. How about YYMMDD-HHMM instead of the current string?

(0003071)
Blzut3 (administrator)
2012-03-31 18:40

Actually I just realized that Doomseeker's plugin is going to need updating no matter what since the revision is parsed to a unsigned short. So yes, that should work. (The space and the colon still need to be removed since they may cause needless headaches on some systems.)

(0003101)
Torr Samaho (administrator)
2012-04-01 22:37
edited on: 2012-04-01 22:38

I shortened the string to YYMMDD-HHMM and hope we can keep it like this. Are any changes necessary on skulltag.net if the new build archives have names like SkullDev98e-120401-2003windows.zip?

(0003104)
Blzut3 (administrator)
2012-04-01 22:42

Took a quick look at the script and it appears right now it will show up as r120401, but it might also not display the downloads. I'll get it fixed once you have a release up. In the mean time if it doesn't work you can just put the links in the thread.

(0003105)
Torr Samaho (administrator)
2012-04-01 22:47

> In the mean time if it doesn't work you can just put the links in the thread.

Ok.

(0003149)
Torr Samaho (administrator)
2012-04-06 01:09

Everything seems to be working fine now -> resolved.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Notes
(0002934) Torr Samaho (administrator) 2012-03-28 00:36	I agree that the revision number is fragile and that it's probably a good idea to move away from it, but how can it go out of sync in a clean clone?

(0002935) Blzut3 (administrator) 2012-03-28 00:40	So you build from a clean clone as well? All I can tell you is if I build the tip I get the following: "src/svnrevision.h updated to revision 3414." The clone was done just a few minutes ago (using https), but just to be sure I ran hg pull and hg up -r tip.

(0002939) Torr Samaho (administrator) 2012-03-28 01:41	> So you build from a clean clone as well? No, but my clone should be identical to the bitbucket repo. To confirm this I just made a clean clone and "hg identify -n" returns the same number for the clean one and the one that I use to build the binaries. Which hg version are you using? I'm using 2.1.1. (actually tortoisehg-2.3.1).

(0002947) Blzut3 (administrator) 2012-03-28 02:01 edited on: 2012-03-28 02:11	Hmm, interesting. I pulled your latest changes and it said it updated to 3416. Then when I went to modify updaterevision.c for debug purposes it fixed itself and now reads the revision correctly. I have no idea what caused that to happen. But in any case I'm uploading a new build now. I'll check the OS X build once that's done. Regardless, it seems this needs to be changed sooner rather than later. Edit: The Mac OS X build was showing the wrong, lower number as well. Same procedure fixed it, didn't even touch hg.

(0002949) Blzut3 (administrator) 2012-03-28 02:20	Added some information no how you would go about getting the information from Mercurial, don't really have time to personally fix updaterevision since I need to work on term projects for school.

(0002960) Torr Samaho (administrator) 2012-03-28 11:51	That looks promising. I'll look into it.

(0002981) Torr Samaho (administrator) 2012-03-29 02:24	I started to investigate this and think using 'hg log -r. --template "{date\|hgdate}"' and running the first number this command returns through the localtime command will do the trick (I want to create a single number based in the date in the format YYYYMMDDHHMM). More on this when I have more time, hopefully tomorrow.

(0002983) Blzut3 (administrator) 2012-03-29 03:13	Storing the changeset hash as well would probably be a good idea. It would help verify the exact changeset used for those who care. (Particularly me since it might take awhile for me to get the Mac and 64-bit builds up depending on where I'm located when you do a release.)

(0003032) Torr Samaho (administrator) 2012-03-30 02:13	I finished a first implementation using the YYYYMMDDHHMM approach for the version string and using the hgdate number as version number. It's not very likely that two commits are made during the same minute the revision an official beta build uses. Do you still think we need the changeset hash? And if so, where should it be displayed?

(0003035) Blzut3 (administrator) 2012-03-30 02:23	I think the changeset hash would be much more convenient than looking through the logs for a commit that matches a given date (unless there's a good way to find it that I'm not aware of). I'm guessing you don't want to clutter the console with information most users don't care about, so I would suggest adding a "changeset" command or something that displays the changeset hash. (I would of course suggest also posting the changeset hash when you announce the builds.) I would also suggest only using YYYYMMDD for the normally visible version number as it's unlikely that we'd produce two beta builds in the same day. It'd be less cluttered in appearance at least. The HHMM could be saved for the changeset command as well.

(0003051) Torr Samaho (administrator) 2012-03-31 13:42	A "changeset" command (possibly "version_info" is a little more self explanatory name) is a good idea. > I would also suggest only using YYYYMMDD for the normally visible version number as it's unlikely that we'd produce two beta builds in the same day. That's certainly true for the official beta builds. I often release several unofficial beta builds during one day though, this would make it harder to distinguish those. We can also (additionally) shorten the year to YY (or even just Y).

(0003067) Torr Samaho (administrator) 2012-03-31 17:45	I added the "version_info" command.

(0003069) Blzut3 (administrator) 2012-03-31 18:01	That works for me. I imagine you're not going to use the underscores in the package file names (SkullDev98e-20120331platform[-arch].[ext])? Just wondering if I need to change anything on skulltag.net. I guess one other thing I worry about is how the version is reported in the query protocol. Right now Doomseeker will try to download "r2012_03_31 17:44" and accordingly try to put that into the SkullDev file name.

(0003070) Torr Samaho (administrator) 2012-03-31 18:18	I hope we can continue to use the same version string in the filenames and in the game itself. How about YYMMDD-HHMM instead of the current string?

(0003071) Blzut3 (administrator) 2012-03-31 18:40	Actually I just realized that Doomseeker's plugin is going to need updating no matter what since the revision is parsed to a unsigned short. So yes, that should work. (The space and the colon still need to be removed since they may cause needless headaches on some systems.)

(0003101) Torr Samaho (administrator) 2012-04-01 22:37 edited on: 2012-04-01 22:38	I shortened the string to YYMMDD-HHMM and hope we can keep it like this. Are any changes necessary on skulltag.net if the new build archives have names like SkullDev98e-120401-2003windows.zip?

(0003104) Blzut3 (administrator) 2012-04-01 22:42	Took a quick look at the script and it appears right now it will show up as r120401, but it might also not display the downloads. I'll get it fixed once you have a release up. In the mean time if it doesn't work you can just put the links in the thread.

(0003105) Torr Samaho (administrator) 2012-04-01 22:47	> In the mean time if it doesn't work you can just put the links in the thread. Ok.

(0003149) Torr Samaho (administrator) 2012-04-06 01:09	Everything seems to be working fine now -> resolved.

Issue History
Date Modified	Username	Field	Change
2012-03-28 00:19	Blzut3	New Issue
2012-03-28 00:36	Torr Samaho	Note Added: 0002934
2012-03-28 00:40	Blzut3	Note Added: 0002935
2012-03-28 01:41	Torr Samaho	Note Added: 0002939
2012-03-28 02:01	Blzut3	Note Added: 0002947
2012-03-28 02:11	Blzut3	Note Edited: 0002947	View Revisions
2012-03-28 02:20	Blzut3	Note Added: 0002949
2012-03-28 02:20	Blzut3	Additional Information Updated	View Revisions
2012-03-28 11:51	Torr Samaho	Note Added: 0002960
2012-03-28 11:51	Torr Samaho	Assigned To	=> Torr Samaho
2012-03-28 11:51	Torr Samaho	Status	new => assigned
2012-03-29 02:24	Torr Samaho	Note Added: 0002981
2012-03-29 03:13	Blzut3	Note Added: 0002983
2012-03-30 02:13	Torr Samaho	Note Added: 0003032
2012-03-30 02:23	Blzut3	Note Added: 0003035
2012-03-31 13:42	Torr Samaho	Note Added: 0003051
2012-03-31 17:45	Torr Samaho	Note Added: 0003067
2012-03-31 17:45	Torr Samaho	Status	assigned => feedback
2012-03-31 18:01	Blzut3	Note Added: 0003069
2012-03-31 18:01	Blzut3	Status	feedback => assigned
2012-03-31 18:18	Torr Samaho	Note Added: 0003070
2012-03-31 18:40	Blzut3	Note Added: 0003071
2012-04-01 22:37	Torr Samaho	Note Added: 0003101
2012-04-01 22:38	Torr Samaho	Note Edited: 0003101	View Revisions
2012-04-01 22:42	Blzut3	Note Added: 0003104
2012-04-01 22:47	Torr Samaho	Note Added: 0003105
2012-04-06 01:09	Torr Samaho	Note Added: 0003149
2012-04-06 01:09	Torr Samaho	Status	assigned => resolved
2012-04-06 01:09	Torr Samaho	Fixed in Version	=> 1.0
2012-04-06 01:09	Torr Samaho	Resolution	open => fixed
2012-06-09 13:22	Torr Samaho	Category	General => Bug
2018-09-30 19:53	Blzut3	Status	resolved => closed

Relationships