Talk:Subversion

Wil 21:43, 21 February 2008 (CET) For the new vdf-guidance subversion server we are discussing setup details, we figured it would be useful to continue the discussion in the open and do it here. Unfortunately that means you are dropping in the middle of a discussion. will try to make it readable a bit.

The current setup questions are:

1. What to put on the global ignore list
   1. No parts that can easily be generated
2. How to setup the default project structure
   1. Should we use trunks and branches?

Global Ignore list

One of the things which we want to customize for using subversion with DataFlex files is the global ignore list. See:

/etc/subversion/config
       

I've just looked over it and i think we want to add the following file types to the ignore list:

*.log             --> No storing of logfiles in our repository
.AppleDouble      --> Ignore apple resource forks (making sure i'm not messing up the repository with my macbook)
*.tre             --> Studio tempfile treeview
*.dsk             --> Studio tempfile
*.pr*             --> DataFlex prn and prp files (compiler output)
*.dbg             --> DataFlex debug files
*.loc             --> Studio tempfile VDF12+

We don't want precompile files

*.fld      --> the compiled object code 
*.pbg      --> precompile debug symbols
*.pdp      --> A DEC PDP 11 file (of course not), but it's undocumented, seems to contain filenames and paths
*.pkd      --> Debug package include file
*.prp      --> PRN file for the precompile

We don't want the following parts from the data files

*.dat      --> Database file, don't add as it changes too much
*.k*       --> Index file, don't add
*.vld      --> Compressed database file, don't add 
*.td       --> Mertech direct driver database cache file, don't add
*.cch      --> DAW direct driver database cache file, don't add
       

I'm wondering if we should remove .exe files as well as those can be compiled from scratch and don't really belong in a source repository in my opinion. In my opinion a released binary should just be put available as download, not versioned.

A database should be backed up, not versioned.

We could opt for having prn and prp files stored in the repository as they actually do contain valuable information and i know that Sture uses them for troubleshooting (me too sometimes) For the data files, at the very least we should version .def .tag .fd files as they are all plain text files and i think we _do_ want to know it if they change.

Matt 21:43, 20 February 2008 (CET) Is there any benefit in keeping .res files in the repository? We haven't seen the need to in house. I agree with the ignore list, imo anything that can be generated easily I wouldn't want to store in subversion. Wil 19:59, 5 March 2008 (CET) Agreed they should be generated on the client machine, so you can't compile without having the control installed. That is a good thing. Besides i don't think this format is still in use since VDF12.0 (or 12.1?)

But what to do with the files DDClasslist.xml and Classlist.xml ? Wil 19:59, 5 March 2008 (CET) We want them

Why trunks and branches

Seems to me that this is only useful to apply to the bigger projects like "The Hammer", cWindowsEX, etcetera. where you actually will end up having multiple active branches (the alternative is to use compiler directives *yuck*) as not all projects are always used in the latest vdf version only.

I really do not wish to push developers to the last version, it is _their_ choice, something that is deemed important with open source. Besides that, not every company wants to have the overhead of having to bring your application to the next dataflex version on a yearly bases. Remember this -usually- small step means that you must retest everything when taking Q&A seriously.

OTOH bogging down the code with compiler directives makes the code harder to manage, read and understand. So for the moment my suggestion is to only use branches for the bigger projects. I suppose we can always add a branch later on if a package needs it?

jka 21:43, 21 February 2008 (CET) Know I actually think about it - I don't think there will be any issues in setting up the default structure of the svnserver to allow for branches for all projects

- I mean you _have_ to actively choose to make a branch if you don't codily happily along in the trunk . So for me it could be a good - clean approach to support branches for all projects pr. default.

It will be harder to make a branch somewhere in the future if we don't support it from the start - so maybe we should give it some more thought. Maybe have a vote?

I vote 'aye' for supporting branches pr default on all projects on svn.vdf-guidance.com.

Wil 21:51, 21 February 2008 (CET) Ok, setting it up in a consistent way sounds pretty good to me.

repository layout

We have one repository for each project - so that the version only increases on the relevant project. (E.g . commits to the VdfQuery project only increases the build number on VdfQuery and not the other projects an vice versa).

I found this link in the svn docs: http://svnbook.red-bean.com/en/1.1/ch05s04.html#svn-ch-5-sect-6.1 . It seems relevant --Jka 22:31, 21 February 2008 (CET)

/VdfQuery/trunk
/VdfQuery/branches
/VdfQuery/tags

/cWindowsEx/trunk
/cWindowsEx/branches/vdf7
/cWindowsEx/branches/vdf121
/cWindowsEx/tags

Wil 14:23, 22 February 2008 (CET) Well i was actually looking at similar documentation for TortoiseSVN (windows help, so no link) when i brought up the whole branch/trunk issue. I was really hoping on being able to use a single repository layout for storing all projects. That would definately help in keeping things simple. OTOH, i note in your reference that it means less flexibility for authentication methods. The folder structure above looks good.

FWIW, after a bit of a struggle with apache i've now changed the url scheme so that you can now browse the repository like this: http://svn.vdf-guidance.com/VdfQuery/