How to maintain identical mission on different islands using SVN?

[Tankbuster 1733]

I'm a very basic level SVN user. Commit, update and view log are about as far as I go.

 

The mission I'm making is on Altis and now, obviously, I want to parallel develop it for Tanoa.

 

What's the best and simplest way to go about this? Should I try to run two separate repositories? Is there a way of pushing code that I've edited in the Altis repo over to the Tanoa one?

[das attorney 857]

Not using SVN, but I normally delete everything except mission.sqm in the mission folder I'm updating to and copy all my other folders/files (except mission.sqm) over from the other mission.

[Grumpy Old Man 3540]

Link shell extension for all files except mission.sqm, with symbolic links.

Good thing is you can delete the links without deleting the source files.

 

Cheers

[kylania 567]

Good thing is you can delete the links without deleting the source files. 

 

 

I did that once in Linux.  Didn't realize the folder I was moving ALL my stuff to was a link so I copied it all over, make sure I could see everything in both places.. and deleted the originals.  Ouch.

[pedeathtrian 99]

Approach 1.

1. Separate all your content into two categories: 1) common to any island (make more use of function files (and not files of many functions)), and 2) specific to some island

2. Create some build system for your mission, which would build .pbo's for all islands (or only some) at once, e.g. batch file performing these steps:

a) copy all common files to temporary build directory

b ) copy specific files to temporary build directory

c) build mission file

d) remove temp directory

e) repeat a-d for next island

OR if your PBO toolkit supports, build mission taking files from different places when needed (according to build rules, e.g. using different command arguments, etc.).

OR (as already suggested) construct full source trees using hard or symbolic links for common files (and separate files for specific)

Using links with VCSs is seeking for trouble.

 

Pros: no branches; easier modifying, maintaining,automating, changelogging, etc.

Cons: build system (probably not a big problem; also could be part of repository)

 

Approach 2.

1. Separate all your content into two categories: 1) common to any island (make more use of function files (and not files of many functions)), and 2) specific to some island;

2. Make a VCS branch for every island.

3. Merge changes in only common files from changed branch to all other branches. Specific files are not merged.

4. Build mission for every island from its own branch.

 

Pros: easier to build mission for (specific) island, no need of build system.

Cons: branches: keeping all branches intact and up-to-date gets harder with more branches/islands; harder to automate

 

Git fits more for heavy branchwork than SVN, so I suggest first approach (or second with Git).

[Tajin 348]

For everything that is only required by the server (scripts mostly) you can also move the files into a subfolder on your server ArmA3-directory root and have the missions load them from there.

 

That also makes it easy to edit stuff on the fly, while the server is running.

 

 

 

I use the same approach for server-side addons, where I basically only put the config.cpp into the PBO and leave everything else outside. No more having to restart the server when making a change to the addon.

[Grumpy Old Man 3540]

Good info, gotta try that, thanks.

 

Cheers

[Tankbuster 1733]

Guys, thank you all for replies.

 

For the time being, I'm using das attorneys method because it's simple and quickest to action but I will look into how the simlinks work. I'll need to sit down and read up on what it does.

 

@tajin, I see what you mean about editing on the fly. Because I really only get a couple of hours a day making the mission, I usually keep the updates local until there's a milestone ready, then I put it on the server, which is a rented box.

 

@dedeathtrian, there's almost no island specific scripts stuff. The mission was made this way from the get-go to make porting easier. A few of the scripts have if (worldname == "Altis") type sutff, so they'll have to fixed up, but I'm hoping that planning for porting from the very early days of making the mission is going to pay dividends now.

[Tajin 348]

 I usually keep the updates local until there's a milestone ready

 

The same thing also works on your local machine ofcourse.

[Tankbuster 1733]

Grumpy's suggestion is working a treat. As far as I can see, the moment I save a change in the .altis mission folder, it gets whooshed over to the copy in the .tanoa mission folder! Not only does it work, but I learnt something new today! Win and win. :) Is there a downside that I've yet to uncover?

[Grumpy Old Man 3540]

Grumpy's suggestion is working a treat. As far as I can see, the moment I save a change in the .altis mission folder, it gets whooshed over to the copy in the .tanoa mission folder! Not only does it work, but I learnt something new today! Win and win. :) Is there a downside that I've yet to uncover?

No downsides, been using this since A2, set up ramdisk, push original files on the ramdisk, create symbolic links in the game folder, all kinds of stuff.

Don't forget to make your regular backups though, in any case.

It's great since you only have to set up the most basic mission.sqm on a new map, create the symbolic links and you're ready to go.

 

Cheers

[Tankbuster 1733]

Yeah, ONLY the mission.sqm is different. Every other file is common and identical in both mission folders. Backups are taken care of via the SVN, which is on a remote system.

[das attorney 857]

Link shell extension for all files except mission.sqm, with symbolic links.

Good thing is you can delete the links without deleting the source files.

 

Cheers

 

 

Thanks very much for this - I hadn't even thought about symbolic links but they're great - I can now have one copy of scripts and update 4 missions at the same time.

 

Cheers mate  :)

[AZCoder 921]

Thanks very much for this - I hadn't even thought about symbolic links but they're great - I can now have one copy of scripts and update 4 missions at the same time.

 

Cheers mate   :)

 

It really pays to read this forum. I had been keeping common scripts in a 'scripts' subfolder on the root of missions because it's automatically searched when previewing a mission, but had to add the filepatching flag recently to keep it working. But symbolic links would free me from that. Thanks for mentioning it!

[Tankbuster 1733]

It's worth mentioning that more and more stuff is being moved out of description.ext into the sqm. All the BIS revive settings, for example.

 

As Grumpy says, you will be wanting to symbolic link all of your mission files APART from the SQM, so be sure to manually update the SQM of all your child missions.

[Tankbuster 1733]

On 20/07/2016 at 6:59 PM, das attorney said:

 

 

Thanks very much for this - I hadn't even thought about symbolic links but they're great - I can now have one copy of scripts and update 4 missions at the same time.

 

Cheers mate  :)

 

Just to confirm... with Malden coming soon I can have a second ( in the future, many more) copy being automatically updated from a single source?

[das attorney 857]

Yes, I've added in my Malden version of mission - just copy an existing mission folder and append the end to

.malden

 Then delete everything except the mission.sqm from the new malden versoin of your mission.

 

Then symlink your scripts & folders from your "master" version (but not the mission.sqm)  into the malden version and adjust any editor placed objects/markers etc to suit.

 

Should only take a couple of minutes or so.

[Tankbuster 1733]

Excellent. Thanks, mate.

[Tankbuster 1733]

Here's how to actually do this thang. Because I have to refer to this thread every time and I know a couple of other users want to know because they've asked me. 🙂
If you haven't already, install link shell extension.

1.  Create a new mission folder, give it an appropriate name - the extension is typically the terrain name.
2. Go to the source directory.
3. Select everything in there except for the mission.sqm and any files or folders created by IDE applications. Mine, for example has a hidden .svn folder and a .vscodefolder. You don't want to select any of those .
4. While they are selected, in the right click menu select Pick Link Source.
5. Go to the folder you created earlier and right click in there, select Drop as, then select Symbolic Link. The files will all appear after a short delay.
6. You will need to make your own mission.sqm which you can do in the mission editor.
7. In the mission editor, go to Attributes>General and change the Title to something appropriate.

Now, every file edit you make in the source directory is quickly copied over to the new directory.

 

Note that you need to be disciplined and careful when loading mods and saving the mission in the editor. If you load up a vanilla mission into the editor while you have mods loaded and save it, you will overwrite your vanilla SQM with a modded one and that's never good. Keep a backup of those SQMs. I suggest turning autosave off in settings>preferences in the mission editor.

[gc8 970]

6 hours ago, Tankbuster said:

If you haven't already, install link shell extension.

 

Is it safe? (No viruses) 

 

[Tankbuster 1733]

Oh yes. I've been using it since the discussion started and @Grumpy Old Manpresumably using it even before that. Always submit the files to your virus checker, obviously.

[pierremgi 4739]

Interesting. I'm discovering the tool.

Are you using hardlink (for true updated copy if I'm right), or symbolic link? In this case, I understand it's just a link, so what about when you pbo the mission with sub-folders definitions & paths? And perhaps, even heavy scenarios don't exceed few Mo, so a smart copy with LSE should be fine...

[Tankbuster 1733]

A symbolic link. I thought it's 'just' a link too, but the target folders can be made into a PBO just as I'd hoped. I now have 3 target folders coming off the source folder and it's working a treat. The subfolders and stuff like that all work just fine.

Something to bear in mind.. If you create a new file or folder in the root of the mission folder, you have to create a new link. Also, don't select the SQM as for me, they have to be different in each destination folder.

 

As we discussed earlier, this is primarily for making copies of a mission folder for multiple builds of a mission. For example, all my scripts are in my authority.altis folder. When I make changes, they are copied to the authority.tanoa, authority_rhs.altis and authority_rhs.tanoa. The folders are identical APART from the mission.sqm.

[engima 327]

On 9/5/2016 at 10:02 PM, Tankbuster said:

It's worth mentioning that more and more stuff is being moved out of description.ext into the sqm. All the BIS revive settings, for example.

 

Hey, wait a minute! So writing the revive settings in description.ext does not override mission.sqm anymore? That would explain why I have difficulties getting it to work...

 

I too have the same mission on many different maps. Is there another way to keep revive settings across mission files without having to enter them explicitly for every new mission file?

[Tankbuster 1733]

I'm not sure. I always assumed the description.ext settings, if given, took precedence.