485
edits
Talk:Subversion: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 14: | Line 14: | ||
I've just looked over it and i think we want to add the following file types to the ignore list: | I've just looked over it and i think we want to add the following file types to the ignore list: | ||
*.log | *.log --> No storing of logfiles in our repository | ||
.AppleDouble | .AppleDouble --> Ignore apple resource forks (making sure i'm not messing up the repository with my macbook) | ||
*.tre | *.tre --> Studio tempfile treeview | ||
*.dsk | *.dsk --> Studio tempfile | ||
*.pr* | *.pr* --> DataFlex prn and prp files (compiler output) | ||
*.dbg | *.dbg --> DataFlex debug files | ||
*.loc | *.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. | 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. | 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) | 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. | |||
[[User:Hellboy1975|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. | |||
[[User:Wil|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 ? | |||
[[User:Wil|Wil]] 19:59, 5 March 2008 (CET) We want them | |||
===Why trunks and branches=== | ===Why trunks and branches=== | ||
| Line 37: | Line 62: | ||
I suppose we can always add a branch later on if a package needs it? | I suppose we can always add a branch later on if a package needs it? | ||
[[User: | [[User:jka|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 | 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 | ||
| Line 47: | Line 72: | ||
[[User:Wil|Wil]] 21:51, 21 February 2008 (CET) Ok, setting it up in a consistent way sounds pretty good to me. | [[User:Wil|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 --[[User:Jka|Jka]] 22:31, 21 February 2008 (CET) | |||
/VdfQuery/trunk | |||
/VdfQuery/branches | |||
/VdfQuery/tags | |||
/cWindowsEx/trunk | |||
/cWindowsEx/branches/vdf7 | |||
/cWindowsEx/branches/vdf121 | |||
/cWindowsEx/tags | |||
[[User:Wil|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/ | |||