An SVN of the GZDoom SVN?

[Nash]

Right now, my so-called "fork" is synchronizing with the official GZDoom SVN.

I got a friend who wants to collaborate, so I want to setup an SVN of my fork. I want me and him to both be able to work on my fork, but ALSO I want to constantly sychronize with the official SVN.

How do I go about this?

[printz]

I'm using Sourceforge. But as a result, everything I do on my project is public. But for being open-source, I'm okay with that...

Make sure it's okay with the ZDoom Licenses before you distribute it under that medium.

[Graf Zahl]

TortoiseSVN allows cross-merging between repositories. But you'll have to remember the revisions you already merged yourself.

Also, due to the licenses involved, if you release a binary, you have to release the source, so no 'here's a demo but we'll hide the source for now to keep our secrets' stuff. If you release a demo, the source code must be released, too.

[Nash]

Yes I am aware of the license issues and it never was my intention to make the source OMG SEKRIT. I guess what I am really interested in is this "cross merging" that Graf mentioned. I'll read up about it...

[Graf Zahl]

Gez may be able to help you. He's done it quite frequently.

[Nash]

Sorry for the bump, I have a quick question. This is all new to me so I'm sorry if the answer is obvious. I'd just like to get things right the first try.

Would it work if I do it this way:

1) TortoiseSVN -> Export a clean copy of my modified GZDoom (including unversioned files since I've added some). Cleaned meaning no .obj/release files, removed .vcproject.user files, etc
2) Checkout that exported folder into my SVN repository

So which one should be my main working project? GZDoom or my fork? I was thinking the former because that gets updated more frequently. So:

- Keep working on the official (modified) GZDoom project.
- When GZDoom receives updates, make a .diff, then apply to fork, then commit updates to fork
- If friend changes anything on the fork on the SVN, use TortoiseSVN -> Merge -> "Merge two different trees" on GZDoom so my copy is updated with his changes.

Does this look correct?

[Gez]

If you have set up an SVN server, you should use that. Work on the fork, commit changes you make. Keep your original GZDoom folder in pristine state, that way you can quickly make comparison tests when you discover a bug.

With TortoiseSVN, merging changes is easy. Just show the GZDoom log, select the revisions not backported yet, and then right-click->merge revisions to:

Spoiler:

Navigate to select your fork folder, and there you go.

If there are any conflicts, you can edit them during the change.

Once it's finished, commit.

[Nash]

When you say "work on the fork"... which one is this exactly?

Just to explain things further, this is my current pipeline:

- SVN checkout original GZDoom SVN
- make changes on this copy - now tons of red exclamation marks because it's different from original stuff
- i consider this my "fork"; I build out my own EXEs from this copy

So what I'd like to do now, is I want to upload this modified copy to my SVN server, so that other people can work on it/download as they please. Let's call it "zombie". And when something in original GZDoom gets updated (via right-click on my copy of GZDoom with the red exclamation marks -> SVN Update), I want to commit these changes to the "zombie" repository so others get the latest original GZDoom fixes.

I can't commit from this folder because if I click that, it wants to commit to the trunk on mancubus.net, which I don't want. All I'm looking for it to commit to "zombie".

This means I'd have to create a separate copy, using TortoiseSVN -> Export. Then from that exported folder, I can commit to zombie's SVN server. Is this correct?

[Gez]

When you say "work on the fork"... which one is this exactly?

The fork is zombie.


That sentence has a nearly dadaist sense of absurd poetry out of context.

[Nash]

But if I work on zombie, when official GZDoom updates, I can't right-click on it and choose SVN Update... I'd have to make a diff patch from GZDoom then apply it to zombie. Right?

[Gez]

Okay, look at this. I guarantee you that I have not personally made any diff patch from ZDoom then applied them to GZDoom. What I did was look at the ZDoom log, select the newest revisions, right-click->"merge revisions to", select GZDoom folder, and done!

In case of conflict between the codebases, you can edit them on the fly. It's a well-designed piece of software.

So, basically, everything I already said above.

[Nash]

Ohhhhhh now I get it. Alright it makes sense now. Thanks Gez. Sorry for the dumb questions.

[Nash]

One last question. How can I get my EXE to start at revision 0? Should I even do this? Or is this a bad idea?

[NeuralStunner]

That basically only affects savegame and demo compatibility - Since saves of your own game will not work in the parent port, i'd say to start at 0. (GZDoom did, after all.)

[Gez]

GZDoom actually uses the ZDoom revision number for saves.

Demo and netplay do not use revision numbers.

Basically, see version.h.

You'll also want to edit src/win32/zdoom.rc in a text editor to change some strings there.