Source code

General discussion of the port and Doom-related chat.
User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Source code

#21

Post by Torr Samaho » Sun Jun 24, 2012 6:30 pm

Wartorn wrote: I don't think there's much to stop us from hosting it on zandronum.com itself :)
In that case, does anybody want to experiment with this?
Dusk wrote: Sorry to derail but, related to snapshots, I still think we should version them to avoid confusion. (1.0-alpha1 for instance)
I'd like to avoid any system where we have to manually assign these numbers.

ZzZombo
Forum Regular
Posts: 323
Joined: Mon Jun 11, 2012 12:11 pm
Location: Ravenholm

RE: Source code

#22

Post by ZzZombo » Mon Jun 25, 2012 1:35 pm

I'd like to avoid any system where we have to manually assign these numbers.
I feel like nobody knows that it's possible to store numbers in a file and make programs take them from there instead of doing all dirty work by hands.

BTW, what's wrong with svnrevision.h? It absent from your repo and my Visual Studio don't want to compile two projects without it.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Source code

#23

Post by Torr Samaho » Mon Jun 25, 2012 8:08 pm

ZzZombo wrote: I feel like nobody knows that it's possible to store numbers in a file and make programs take them from there instead of doing all dirty work by hands.
Are you kidding me? Of course you only need to have this number at a single place, what you do think version.h is doing? And how do you think I changed the version from 98e to 1.0 for instance? You can't be seriously thinking that I'm not aware of this, can you?

What I don't want to do is to manually touch that single file for every beta release I make. I want something that is completely automatic without any kind of manual interaction whatsoever. And we already have such a system and that is supplying the version numbers like 120624-2027. Unfortunately the simple revision numbers are not unique in a DVCS, that's why we moved to this more complicated number.
ZzZombo wrote: BTW, what's wrong with svnrevision.h? It absent from your repo and my Visual Studio don't want to compile two projects without it.
Nothing is wrong with svnrevision.h. It is intentionally not in the repository since it's automatically generated. You need to have the hg client installed on your machine so that the updaterevision tool can use it by just calling "hg ..." on the command line.

ZzZombo
Forum Regular
Posts: 323
Joined: Mon Jun 11, 2012 12:11 pm
Location: Ravenholm

RE: Source code

#24

Post by ZzZombo » Tue Jun 26, 2012 12:14 am

Torr Samaho wrote: Are you kidding me? Of course you only need to have this number at a single place, what you do think version.h is doing? And how do you think I changed the version from 98e to 1.0 for instance? You can't be seriously thinking that I'm not aware of this, can you?

What I don't want to do is to manually touch that single file for every beta release I make. I want something that is completely automatic without any kind of manual interaction whatsoever. And we already have such a system and that is supplying the version numbers like 120624-2027. Unfortunately the simple revision numbers are not unique in a DVCS, that's why we moved to this more complicated number.
Hey, I am not kidding you, I just mean you can put this build number in any file, isn't it? So you can leave current version numbers intact and change only build number which is placed in a separate file which in fact could consist only of this number. I'm sorry if I said something unclear.

Oh, I forgot that it's C++... I used to my own buildbot in Delphi which after a build just renames compiled binaries and patches their version info.
Torr Samaho wrote: Nothing is wrong with svnrevision.h. It is intentionally not in the repository since it's automatically generated. You need to have the hg client installed on your machine so that the updaterevision tool can use it by just calling "hg ..." on the command line.
But I have hg client installed. What I must to do to configure it to work with Studio?
Last edited by ZzZombo on Tue Jun 26, 2012 12:22 am, edited 1 time in total.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Source code

#25

Post by Torr Samaho » Tue Jun 26, 2012 8:07 pm

ZzZombo wrote: I just mean you can put this build number in any file, isn't it? So you can leave current version numbers intact and change only build number which is placed in a separate file which in fact could consist only of this number. I'm sorry if I said something unclear.
Of course you can do so and this is essentially what version.h already does, it just contains more than a single number. I'm not talking about how to automatically get the number into the binaries, I'm talking about how to automatically get the number. I don't want to manually say "this is beta build N" for each beta build we release. I would like to have something that assigns this number with absolutely no manual interaction.
ZzZombo wrote: Oh, I forgot that it's C++... I used to my own buildbot in Delphi which after a build just renames compiled binaries and patches their version info.
A build bot that counts how many builds it already generated and automatically patches that number into the source before it compiles the binaries could work.
ZzZombo wrote: But I have hg client installed. What I must to do to configure it to work with Studio?
The directory of the hg command line client needs to be in your search path.

ZzZombo
Forum Regular
Posts: 323
Joined: Mon Jun 11, 2012 12:11 pm
Location: Ravenholm

RE: Source code

#26

Post by ZzZombo » Wed Jun 27, 2012 12:41 pm

Thanks for answers, now I'm happily backporing all needed for my mods fixes/features from ZDoom. Maybe you are interested in my own repo-fork from Zandronum that in the close future will be updated with them?

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Source code

#27

Post by Torr Samaho » Wed Jun 27, 2012 7:46 pm

ZzZombo wrote: Thanks for answers, now I'm happily backporing all needed for my mods fixes/features from ZDoom. Maybe you are interested in my own repo-fork from Zandronum that in the close future will be updated with them?
While I appreciate your intention to contribute to Zandronum, as general policy, I don't pull or accept patches with ZDoom backports . I already announced this and detailed why back on the Skulltag forums. To make it short: Reviewing a ZDoom backport is usually as much work as doing the backport itself, so this doesn't save me any work, it just creates more work for others. Also these individual backports make upgrading the whole ZDoom base more difficult in the future.

If you want to contribute anything other than ZDoom backports though, that would be highly welcomed!

ZzZombo
Forum Regular
Posts: 323
Joined: Mon Jun 11, 2012 12:11 pm
Location: Ravenholm

RE: Source code

#28

Post by ZzZombo » Thu Jun 28, 2012 2:16 am

Huh, I was forced to fork and backport because you said that you plan to do that yourself after an unknown possibly long period of time and that is very bad. Currently Zandronum very limited in terms of modding in comparision with ZDoom (I remember I complained about that on the tracker). And I see no point why you think that reviewing backports made by others doesn't save anything since at least I always check every backport in game and create test WADs for that purpose if necessary and you can be sure it works fine if I commit a changeset to the repo. It actually saves time since every submission is at least adopted to Skulltag, it's not just "copy-and-paste". Also many of fixes I could do myself, then open a ticket on the tracker and ask for pulling them. Both pull requests will be exactly the same, only sources of their origins are different.

User avatar
Torr Samaho
Lead Developer
Posts: 1543
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

RE: Source code

#29

Post by Torr Samaho » Sat Jun 30, 2012 5:55 pm

ZzZombo wrote: Huh, I was forced to fork and backport because you said that you plan to do that yourself after an unknown possibly long period of time and that is very bad.
I plan to resume upgrading Zandronum's ZDoom base as soon as 1.0 is finished.
ZzZombo wrote: And I see no point why you think that reviewing backports made by others doesn't save anything since at least I always check every backport in game and create test WADs for that purpose if necessary and you can be sure it works fine if I commit a changeset to the repo. It actually saves time since every submission is at least adopted to Skulltag, it's not just "copy-and-paste".
You'll have to trust me on this. And even if you don't take into account how much work the code review is, all these cherry-picked backports make upgrading the whole ZDoom base more difficult later on.
ZzZombo wrote: Also many of fixes I could do myself, then open a ticket on the tracker and ask for pulling them. Both pull requests will be exactly the same, only sources of their origins are different.
I will happily pull fixes for Zandronum bugs or new Zandronum features (as long as they are well made and follow our conventions), I will just not pull ZDoom backports (neither backported fixes, nor features).

Post Reply