Different subsets in the same directory
Say I have 5 sets of shell-scripts (A, B, C, D and E). On one computer I want all in ~/bin, on another I want A and B in ~/bin, on another I want A, C and D in ~/bin, etc. Is there a best practise to do this, or should I make several sub-directories in ~/bin? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Tortoise and editing files on a server
I am new to subversion and also not a Windows user. I am asked to create a repository for a company. The programmers will be using Windows PC's to do there work. But the files they are working on will be on a web server, not on there local PC. So there edits will be on remote files. In principal they want to use tortoise. How should this be implemented? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
recursive propedit
I am executing: svn propedit svn:ignore . But this works only on the current directory. I like to have it work on all the directories beneath the current directory also. And if possible on the directories that will be created in the future. Is this possible? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Re: Upgrade subversion 1.5.1
Op maandag 21 mrt 2011 17:18 CET schreef Ryan Schmidt: I am asked to implement a repository system for a client. When looking at the version, I see: svnserve, version 1.5.1 (r32289) compiled Mar 1 2011, 17:20:34 I find this a bit strange. Only three weeks ago compiled, but still on 1.5.1. Should I ask them to upgrade, or is that not very important? I recommend you upgrade to the latest version, 1.6.16. Early 1.5.x versions had some bugs with the new merge tracking feature. They upgraded it to: svnserve, version 1.6.12 (r955767) compiled Mar 7 2011, 06:43:32 It is a Debian system and this is the version that will be distributed with the next Debian. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Upgrade subversion 1.5.1
I am asked to implement a repository system for a client. When looking at the version, I see: svnserve, version 1.5.1 (r32289) compiled Mar 1 2011, 17:20:34 I find this a bit strange. Only three weeks ago compiled, but still on 1.5.1. Should I ask them to upgrade, or is that not very important? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Re: Upgrade subversion 1.5.1
Op maandag 21 mrt 2011 17:20 CET schreef Andy Levy: I am asked to implement a repository system for a client. When looking at the version, I see: svnserve, version 1.5.1 (r32289) compiled Mar 1 2011, 17:20:34 I find this a bit strange. Only three weeks ago compiled, but still on 1.5.1. Perhaps they compiled from old source? That is a possibility. Should I ask them to upgrade, or is that not very important? If you're doing a brand-new installation, I can't see any reason to use such an old release. At a minimum, you should be running the latest in the 1.5 series, but 1.6.x would be even better. There have been several security fixes since 1.5.1, not to mention all the usual bug fixes and in the case of 1.6, new features. When 1.7 is released (no date set), support for 1.5 will cease. Okay, I'll try to convince them. Was what I expected, but a check does not hurt. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Re: svnserve and passwords
Op maandag 21 mrt 2011 18:37 CET schreef Nico Kadel-Garcia: Cool. Check out http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache to learn more about the credential caching. Unfortunately, while that Interesting, but it is another problem. I would like the user to change his password for subversion. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Better way to create project?
I just put my bin folder in subversion. I am a new user, so maybe I do not do things in the right way. So I would like to know if there is a better way to do things. I moved my bin folder to bin.old. I created a bin folder in my repository. I did a checkout of the bin folder. I moved the files from bin.old to bin. I removed bin.old. I did a svn add. I did a svn commit. This are quit a few steps. Is there a better way to do this? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
MySQL changes into svn
I am just asked if it is possible to put the changes of MySQL databases in svn. I could of-course export the table definitions and store those in svn. I was just wondering if there is a better way? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Re: Possibility to commit from 'all' systems
Op woensdag 19 jan 2011 09:40 CET schreef shriniva...@collab.net: SVNSERVE_OPTIONS=-d -r /srv/svn/repos But this means that I can only make changes on the system svnserve is running on. Is there a safe way to have the possibility to change the files on 'all' systems? We can commit files to the svn server. i.e where svnserve is running. Please explain more on what you mean by 'all' systems? I do not know what was happening. First I could only commit on the system the server was running on. And also only with file:///, when I used svn:// I got a message that it was not possible. But now all systems work. I do not know what was happening. I still have to learn a lot, but at the moment it is less urgent. One question remains (again not very important, because I am the only working on it at the moment, but when it expands, I should know what I am doing). What is mend with: # default options for the svnserve process # it is recommended to provide only readonly access to your data. # there is no authentication possible, everyone can read and write at will # read the subversion documentation about more info -- Cecil Westerhof M cecilwester...@xs4all.nl O ascii ribbon campaign - stop html mail - www.asciiribbon.org Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/
Re: Possibility to commit from 'all' systems
Op donderdag 20 jan 2011 16:57 CET schreef Stefan Sperling: # default options for the svnserve process # it is recommended to provide only readonly access to your data. # there is no authentication possible, everyone can read and write at will # read the subversion documentation about more info Which is coming from where? On my system (openSUSE 11) it is in: /etc/sysconfig/svnserve That text should be changed or removed, it is totally misleading. svnserve can authenticate users in various ways. See http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth I thought I had read something like that. ;-} I will notify the openSUSE people. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Possibility to commit from 'all' systems
I just started with subversion. In /etc/sysconfig/svnserve it states: ## Path:Network/Subversion/svnserve ## Description: Basic configuration for svnserve ## Type:string ## Default -d -R -r /srv/svn/repos # # default options for the svnserve process # it is recommended to provide only readonly access to your data. # there is no authentication possible, everyone can read and write at will # read the subversion documentation about more info # SVNSERVE_OPTIONS=-d -r /srv/svn/repos But this means that I can only make changes on the system svnserve is running on. Is there a safe way to have the possibility to change the files on 'all' systems? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
