Re: Import manually versioned files
On 12/20/2016 10:54 PM, Tim Erickson wrote: We are installing Subversion on one of our servers for the first time. We have been manually versioning files via a simple directory structure by keeping a version/date directory under the source. This is where we keep old source code. When importing the repository for the first time, is there a way to import all the old source with the current source in a way that it will look like Subversion was actually doing the versioning all along? Shouldn't be much work to write a custom script copying over the files from your older folders successively over the new files and do according svn add/del/ci calls for each version. I'm not aware of an existing tool/script doing precisely what you need, but it should not be more than a few hours workto write one, I guess. -- Regards, Stefan Hett, Developer/Administrator EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany Tel: +49 2405 4239970, www.egosoft.com Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
Re: environment variable for location of the .svn directory ?
Hello Hugh, > Is there an environment variable that can be used > to specify the location of the .svn directory ? The only method to alter the .svn path (that I am aware of) is the the SVN_ASP_DOT_NET_HACK http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc > If not, is this planned for a future version ? What is the problem you are trying to solve? Andreas
Re: Subversion 1.6 / 1.7 compatibility - RHEL/CentOS 6/7 upgrade
On 20.12.2016 22:41, Todd Armstrong wrote: > >> On Dec 20, 2016, at 8:31 AM, "Matt Garman" wrote: >> >>> On Tue, Dec 20, 2016 at 1:49 AM, Nico Kadel-Garcia wrote: On Mon, Dec 19, 2016 at 6:10 PM, Matt Garman wrote: Looking at the Subversion 1.7 release notes[2], and also my own testing, it appears that what I could do to make this easy for everyone is to upgrade all CentOS 6 clients to subversion-1.7 (i.e. have subversion-1.7 everywhere on the client side). Then everyone can do an "svn upgrade" on all their working copies and go about their business as usual. The svn server can stay CentOS 6 / subversion-1.6 for now (probably done much later in the overall upgrade process). >>> From experience, it's that easy. There is no Subversion 1.7 in the >>> supported repos, and Subversion 1.9 is (from personal experience) >>> awkward to backport to CentOS 6. So it may take some work or >>> searching. I used to publish SRPM tools over at github, but I stopped >>> a while ago. >> Thank you, that is very encouraging. I was able to compile svn-1.7 >> from the vanilla sources on CentOS 6, and my colleague is a pro at RPM >> packaging. So no worries on that front! >> >> Thanks again, >> Matt > WANDisco has freely available subversion binaries for numerous subversion > versions for centos 5, 6, and 7 (and lots of other operating systems. > We are currently using one of the 1.8 versions on both centos 6 and 7 > clients. Don't know if that would be 1.6 server compatible - our server is > 1.8 based as well. As a matter of policy, all Subversion clients are compatible with all Subversion servers[1]. However clients are not compatible amongst each other, due to changes in working copy format (except for 1.8.x and 1.9.x, which both use the same working copy format). In other words, a 1.6 client will talk to a 1.9 server; a 1.7 client will talk to a 1.6 server. Depending on client and server version, some features may not be available or their implementation not be optimal, but day-to-day checkout, update, commit, status, diff etc. will work. Details about compatibility are documented in the Release Notes http://subversion.apache.org/docs/release-notes/ [1] Except that, when using the file:// protocol, it is *highly recommended* to for the client and server to be the same version. In the case of administration tools (svnadmin, svnlook, etc.), version parity is required. These are essentially server-side restrictions and have little bearing on a normal setup, when clients talk to the server using the http:// or svn:// protocol. -- Brane
Re: post-commit hook
João M. S. Silva wrote on Tue, Dec 20, 2016 at 22:37:42 +: > On 12/13/2016 06:09 AM, Daniel Shahaf wrote: > >"smtp_use_ssl" is not a mailer.py configuration knob. > > You are right. I took that setting from a site: > > # added by jmss > # > http://sadomovalex.blogspot.pt/2009/12/use-gmail-smtp-server-for-post-commit.html > smtp_use_ssl = true > > Previously, I could only send mails with that setting I took from the above > blog. It may have become obsolete? If it had become obsolete it wouldn't have been removed from the mailer.py code to maintain backwards compatibility. More likely, that parameter never existed in mailer.py as distributed by us. The comment in that blog suggests it's a local patch by "asadomov". (By the way, Postfix's main.cf configuration file happens to also have a parameter named "smtp_use_ssl"; that knob is, however, entirely unrelated to mailer.conf.) > So, what is the correct/official way to solve this? Make it possible for the configuration file to choose between SMTP_SSL() or SMTP(). I won't be looking into that myself, but if you wish to do so, a patch would be welcome: https://subversion.apache.org/patches Cheers, Daniel
Re: Subversion 1.6 / 1.7 compatibility - RHEL/CentOS 6/7 upgrade
Todd Armstrong wrote on Tue, Dec 20, 2016 at 21:41:57 +: > We are currently using one of the 1.8 versions on both centos 6 and > 7 clients. Don't know if that would be 1.6 server compatible - All 1.x.y clients are compatible with all 1.a.b servers. We won't break wire compatibility until 2.0 (and possibly not even then).
Re: environment variable for location of the .svn directory ?
On 21.12.2016 10:48, Andreas Stieger wrote: > Hello Hugh, > >> Is there an environment variable that can be used >> to specify the location of the .svn directory ? > The only method to alter the .svn path (that I am aware of) is the the > SVN_ASP_DOT_NET_HACK > http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc And to be quite candid, I have no idea if that even works any more ... the code is there, but I'm not aware of anyone having tested Subversion releases with that flag set. As far as I understand it's not very relevant any more (or, rather, that ASP.Net is not relevant). -- Brane
Re: Import manually versioned files
On 21.12.2016 09:46, Stefan Hett wrote: > On 12/20/2016 10:54 PM, Tim Erickson wrote: >> >> We are installing Subversion on one of our servers for the first >> time. We have been manually versioning files via a simple directory >> structure by keeping a version/date directory under the source. This >> is where we keep old source code. When importing the repository for >> the first time, is there a way to import all the old source with the >> current source in a way that it will look like Subversion was >> actually doing the versioning all along? >> >> > Shouldn't be much work to write a custom script copying over the files > from your older folders successively over the new files and do > according svn add/del/ci calls for each version. > I'm not aware of an existing tool/script doing precisely what you need, This is the closest I know of: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/ > but it should not be more than a few hours workto write one, I guess. ... and a couple days to debug it :) -- Brane
Re: Subversion 1.6 / 1.7 compatibility - RHEL/CentOS 6/7 upgrade
Branko Čibej wrote on Wed, Dec 21, 2016 at 11:48:55 +0100: > [1] Except that, when using the file:// protocol, it is *highly > recommended* to for the client and server to be the same version. In the > case of administration tools (svnadmin, svnlook, etc.), version parity > is required. All these — svnadmin, svnlook, and svn over file:// — access a repository on-disk directly, without a mediating server. In these cases, there _is_ in fact a certain amount of leeway — the 1.5 svn* tools can read repositories created by 1.6, for example — but in general it's recommended to use just one version of svnadmin/svnlook/svn on a repository. (For example, because that minimises the chance of running into compatibility bugs.) In general, we promise for on-disk structures — i.e., for the part of the stack where neither svn:// nor http:// is involved — that 1.x.y can read data created by 1.a.b if x ≥ a; which notably includes the case that x=a and y These are essentially server-side restrictions and have > little bearing on a normal setup, when clients talk to the server using > the http:// or svn:// protocol. > > -- Brane > >
RE: Re: environment variable for location of the .svn directory ?
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: Wednesday, December 21, 2016 5:30 AM > To: users@subversion.apache.org > Subject: [**EXTERNAL**] Re: environment variable for location of the .svn > directory ? > > On 21.12.2016 10:48, Andreas Stieger wrote: > > Hello Hugh, > > > >> Is there an environment variable that can be used > >> to specify the location of the .svn directory ? > > The only method to alter the .svn path (that I am aware of) is the the > SVN_ASP_DOT_NET_HACK > > http://svnbook.red-bean.com/nightly/en/svn.basic.in- > action.html#svn.basic.in-action.wc > > And to be quite candid, I have no idea if that even works any more ... > the code is there, but I'm not aware of anyone having tested Subversion > releases with that flag set. As far as I understand it's not very > relevant any more (or, rather, that ASP.Net is not relevant). > > -- Brane Thanks. Andreas asked > What is the problem you are trying to solve? The context is versioning file sets/trees that are used by other applications and processes. In this situation, it is nice or imperative to be able to treat the file set/tree as just the original, but still have it versioned. This is obtained if the versioning tool in no way alters the original file tree. The newer treatment of .svn goes most of the way but does not quite do this. Also, just my untutored mania, it seems cleaner, and provides freedom, to govern the .svn location with an environment variable, since there is nothing in the concept or nature of .svn that would require it to be located as is done now.
Re: Import manually versioned files
> On Dec 21, 2016, at 05:32, Branko Čibej wrote: > > On 21.12.2016 09:46, Stefan Hett wrote: >> On 12/20/2016 10:54 PM, Tim Erickson wrote: >>> >>> We are installing Subversion on one of our servers for the first >>> time. We have been manually versioning files via a simple directory >>> structure by keeping a version/date directory under the source. This >>> is where we keep old source code. When importing the repository for >>> the first time, is there a way to import all the old source with the >>> current source in a way that it will look like Subversion was >>> actually doing the versioning all along? >>> >>> >> Shouldn't be much work to write a custom script copying over the files >> from your older folders successively over the new files and do >> according svn add/del/ci calls for each version. >> I'm not aware of an existing tool/script doing precisely what you need, > > This is the closest I know of: > http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/ That was the script I was going to suggest using as well. Treat your old manually-versioned code as a vendor branch. See the chapter in the svnbook on vendor branches, and previous discussion in the mailing list archives.
