/trunk/tools

[karmazilla]

The project is slowly growing small perifiral pieces of software.

I feel like creating a tools directory under trunk where we can put these little thingies like the pie import plugin for blender and the master server.

However, not wanting to clutter up the trunk, I'm asking your input on this idea first.

[Watermelon]

I think it's better to store the tools outside 'trunk',or the user will be forced to download the tools in 'trunk/tools' when checking out svn?

[DevUrandom]

Yes, that might be a problem.
In general I'd like to have those tools in the SVN, but we currently use trunk for everything...

Maybe we should do something like
/trunk/tools/jmaster
/trunk/tools/pie_import
/trunk/game/*

?

[karmazilla]

Yes, that might be a problem.
In general I'd like to have those tools in the SVN, but we currently use trunk for everything...

Maybe we should do something like
/trunk/tools/jmaster
/trunk/tools/pie_import
/trunk/game/*

?

The alternative to that would be to make tools a sibling of trunk. That would keep trunk more clean and standard looking, but I guess it would have side effects on the "branchability" of tools - I'm not 100% on how branching works in svn, so I can't say how big a loss this is.

Anyway, after some more thought, I agree that we should keep tools out of trunk. Otherwise, the shadow of EditWorld might come back to haunt us in unpleasent ways.

[DevUrandom]

Well, branching in SVN is easily explained: Your SVN repository is like a simple directory. You can create subdirectories however you want. SVN doesn't know CVS-style branches. It only knows different folders, which might have or might not have a special meaning to you. They don't have to SVN.

And I wouldn't necessarily keep the tolls out of the trunk. But if we put them there, we have to move the current trunk out of it. Eg into /trunk/game/

[Giel]

Well, branching in SVN is easily explained: Your SVN repository is like a simple directory. You can create subdirectories however you want. SVN doesn't know CVS-style branches. It only knows different folders, which might have or might not have a special meaning to you. They don't have to SVN.

And I wouldn't necessarily keep the tolls out of the trunk. But if we put them there, we have to move the current trunk out of it. Eg into /trunk/game/

And how about the multi-project directory structure (as proposed in SVN book, the official SVN docs)?

Something like:

game/trunk
game/branches
game/tags

tools/trunk
tools/branches
tools/tags

However I think trunk/tools would probably be better. Because that way you could more easily link the tools against certain gamelibs (for reading pie-files etc.?). Anyway my point: it is easier to reuse code by keeping both in the current trunk (i.e. just adding trunk/tools).

[karmazilla]

Alright.

1. tools as sibling of trunk is the best idea because it'll keep the trunk checkout size down and mark a clear seperation between warzone relate tools and warzone itself.
However, this is also the worst idea because ...?

2. tools as a child of trunk (original proposal) is the best idea because then everyone who does a checkout of the game will simultaniously get (some of) the tools needed produce mods for it, and the tools can directly link to game libs.
However, this is also the worst idea because it'll bump up the checkout size.

3. tools and game as siblings, and both as childs of trunk is the best idea because it'll keep everything in trunk, without mixing them.
However, this is also the worst idea because those who checkout the trunk will have to download a lot, and to reorganize the trunk this way will create a big patch.


Which will it be? I personally still prefer number 1, so I think I'll commit it tonight (the displeased may yell) - just a small addition, so it's easy to change afterwards if it turns out to be a bad idea.

[DevUrandom]

Oha... Siblings and childs and ... (Can I get some "graphical" representation of that?)

What I think and would like to see:
/trunk/tools
/trunk/game

The "patch" for that is actually non-existant, as SVN can very well move files and folders. No need to do that via patches.
It wont even destroy existing patches, as those are relative to the checkout position (/trunk in most cases) and thus applying them is as easy as "cd game; patch -p0 < the.patch".

I am not yet sure if that is the best naming or if it should be split further, but for the time being it is ok.

[karmazilla]

ah, ok. I'm holding it off a while  ::)

Siblings and childs:

/root/child-of-root

/dir/siblingA
/dir/siblingB

Clearer?

On the "patch" (should probably have been "commit"?) size; I'm under the impression that svn does a move with a copy and a delete action - at least 'svn help mv' says so. So moving the whole source tree around will cause rather large commits/change sets/patches/deltas to be uploaded and then downloaded - one time cost, of corse.

[DevUrandom]

I think SVN optimizes such moves away. I think if it sees a "copy without modifications", then it will very probably not download that copy, since it allready has it in the .svn dir...

[karmazilla]

This is also optimized during network IO? I had a feeling it did something like this on the storage side of things but I didn't know it also applied when transmitting change sets (or whatever it's called) over the wire. Well, in that case I'm fine with it.

So we go with
/trunk/tools
/trunk/game

Should I try and commit that?

[DevUrandom]

Did you post it on the mailinglist allready? Probably those want to know about it, too.

[Giel]

Yes, SVN optimizes such moves (it internally stores it as a command to copy /trunk/bleeh@r1 to /trunk/mooh@r2, it also sends this out to the clients so they can check whether they have /trunk/bleeh@r1 present before downloading /trunk/mooh@r2).

Then as for the directory structure:
In case of (1) do you mean something like this:?
/tools/
/trunk/

Because I really don't like that style. Makes branching/tagging less intuitive.

I personally prefer option (2):
/trunk/tools
/trunk/lib
/trunk/src
etc.

However option (3) is fine with me as well:
/trunk/tools
/trunk/game

This only as long as /trunk/tools can always assumed to be checked out as part of /trunk/ otherwise you can't utilize the WZ-libs in the tools. So because of that I would really still prefer option (2) (only adding /trunk/tools).

The checkout size is hardly a problem there IMO (data usually takes up the most space, and most tools will need/have almost no data)

[DevUrandom]

Ok, go with 2 then. You have my ok.

[Giel]

Maybe inform people on the mailinglist first? Because I only stumbled on this topic by accident and that doesn't guarantee others will find it.

Either way I'm not home until 1800-1900 (CET=ZULU+0100) and this place is firewalled like hell. Only allowed outbound ports are 80 and 443 (https), and even those are proxied so that it doesn't support carrying a SSH tunnel.

I believe that on GNA they call it a wrongly configured hostile firewall. Seriously why would anyone want to block outbound ports?