Re: How to store new password so no need to enter every time?
On Thursday, May 3, 2012 3:47:13 PM UTC-4, Stefan Sperling wrote: > > On Thu, May 03, 2012 at 12:41:38PM -0700, frame wrote: > > I saw the password is saved in the file within > .subversion/auth/svn.simple > > directory. Is that correct? How can I have it saved in encrypted format? > Is > > this can be achieved by my personal or the system admin group? > > You would need to configure gnome-keyring or kwallet (see the > 'password-stores' option in the 'config' file). I don't know > whether those programs are available for your linux distro. > They are third-party password encryption tools that Subversion > can optionally make use of. > > Our system admin is against saving password in plain text format. So, I have to pursue encryption format way. In my .subversion/config: ### Section for configuring external helper applications. password-stores = So 'password-stores' option is empty. We use Red Hat Linux 5.8. Can you help more? Thank you.
Re: How to store new password so no need to enter every time?
On Fri, May 04, 2012 at 06:48:10AM -0700, frame wrote: > > > On Thursday, May 3, 2012 3:47:13 PM UTC-4, Stefan Sperling wrote: > > > > On Thu, May 03, 2012 at 12:41:38PM -0700, frame wrote: > > > I saw the password is saved in the file within > > .subversion/auth/svn.simple > > > directory. Is that correct? How can I have it saved in encrypted format? > > Is > > > this can be achieved by my personal or the system admin group? > > > > You would need to configure gnome-keyring or kwallet (see the > > 'password-stores' option in the 'config' file). I don't know > > whether those programs are available for your linux distro. > > They are third-party password encryption tools that Subversion > > can optionally make use of. > > > > Our system admin is against saving password in plain text format. So, I > have to pursue encryption format way. In my .subversion/config: > ### Section for configuring external helper applications. > password-stores = > > So 'password-stores' option is empty. We use Red Hat Linux 5.8. Can you > help more? Thank you. I don't know if gnome-keyring or kwallet are available in Red Hat Linux 5.8, and whether or not support for these features was compiled into Subversion by the Red Hat packagers. Somebody else on this list may know. Or you might want to ask Red Hat directly. If Red Hat 5.8 doesn't ship Subversion with gnome-keyring or kwallet support, you'll have to type the password or ask your admin to upgrade to a newer version of Red Hat or use a different Liunx distribution. Or you might find a build of Subversion for your Red Hat system that has these features enabled -- a good starting point for your search would be http://subversion.apache.org/packages.html All we can do is provide these features. If packagers you obtain Subversion from disable these features or ship outdated versions, the Subversion project cannot help you.
Re: How to store new password so no need to enter every time?
On Fri, May 4, 2012 at 9:59 AM, Stefan Sperling wrote: > I don't know if gnome-keyring or kwallet are available in Red Hat > Linux 5.8, and whether or not support for these features was compiled > into Subversion by the Red Hat packagers. Somebody else on this list > may know. Or you might want to ask Red Hat directly. > > If Red Hat 5.8 doesn't ship Subversion with gnome-keyring or kwallet > support, you'll have to type the password or ask your admin to upgrade > to a newer version of Red Hat or use a different Liunx distribution. > Or you might find a build of Subversion for your Red Hat system that > has these features enabled -- a good starting point for your search > would be http://subversion.apache.org/packages.html Red Hat 5.8 includes a suitable version of gnome-keyring. The RPM that CollabNet provides includes support for GNOME keyring as well as a command line tool for managing the keyring (for users that are not using a GUI desktop). http://www.collab.net/downloads/subversion/linux.html I seem to recall you were asking questions about Subclipse earlier. Note that the Subversion GNOME keyring feature does not work from Eclipse and that Subclipse will force you to disable it in your config. http://subversion.tigris.org/issues/show_bug.cgi?id=3498 However, you can point Subclipse at a custom location for the configuration if you want to use GNOME keyring with your command line. -- Thanks Mark Phippard http://markphip.blogspot.com/
Are some global ignore patterns hard coded in svn?
Hi, all. I presume following global ignore patterns are in some way hard coded in svn (I checked in svn versions 1.6.16 and 1.7.2) *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store So, files matching these patterns are ignored when default configuration files on client machine are used (I mean the system-generated files /etc/subversion/config and ~/.subversion/config); in these default files, global-ignores parameter exactly contains all the above patterns but it is commented out, so I should expect no global ignore could be applied: this is not true. In order to avoid the ignore of files matching those patterns I have to define the global-ignores parameter in config file and set it to empty. Am I missing something? Thanks for your attention. Dario Marini
SVN 1.7.4 checkout not changing files
Hello, I am using SVN 1.7.4 (r1295709) CentOS 5.5, having removed 1.6 and installed the new RPM. In a directory, svn co shows the files that have been added/modified/deleted. However, the files themselves remain unchanged on the filesystem. As a workaround, I need to svn export after an svn co in order for the changes to be made to the filesystem. Is this a known issue or am I missing something about svn (a command-line switch, perhaps?). Permissions appear to be OK as svn export is working. Any questions, feel free to ask -- Regards, James Withers Developer Email: ja...@vortexcommerce.com Tel: +44 (0) 1423 226 554 Mobile: 07903 983 393 Skype: james.robert.withers www.VortexCommerce.com | ja...@vortexcommerce.com Unit 3, 23 Park View, Harrogate, North Yorkshire, HG1 5LY, United Kingdom
During sparse checkout, what's the difference between "svn update --depth" and "svn update --set-depth"?
I am playing sparse checkout feature of subversion. It is working great. It let me completely ignore the portion of the tree that unrelates to me. I just have one thing unclear: 1)svn checkout https:///proj --depth empty In my local area, I will have a directory created with name "proj", since I didn't specify the destination name. The directory is completely empty. 2)cd into the proj directory, now is my confusion. I want the whole tree of proj in my local area. I tried this: svn update --depth infinity //it does not bring anything into my local area svn update --set-depth infinity //yes, it worked Reading "svn help update", I cannot figure out the difference. Thank you very much.
Re: SVN 1.7.4 checkout not changing files
Guten Tag James Withers, am Freitag, 4. Mai 2012 um 09:28 schrieben Sie: > In a directory, svn co shows the files that have been > added/modified/deleted. However, the files themselves remain unchanged > on the filesystem. As a workaround, I need to svn export after an svn co > in order for the changes to be made to the filesystem. Are you really sure that you use svn co? co means checkout and is for creating a fresh new working copy, in those cases there are no added/modified/deleted files. Those only come with svn up for updating an existing working copy. co is only used for the first time, use up afterwards to get the changes from the repo. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Are some global ignore patterns hard coded in svn?
Dario Marini wrote on Fri, May 04, 2012 at 16:04:17 +0200: > In order to avoid the ignore of files matching those patterns I have to > define the global-ignores parameter in config file and set it to empty. > > Am I missing something? No.
Fwd: SVN 1.7.4 checkout not changing files
-- Forwarded message -- From: Nico Kadel-Garcia Date: Fri, May 4, 2012 at 8:53 PM Subject: Re: SVN 1.7.4 checkout not changing files To: James Withers On Fri, May 4, 2012 at 3:28 AM, James Withers wrote: > Hello, > > I am using SVN 1.7.4 (r1295709) CentOS 5.5, having removed 1.6 and > installed the new RPM. > > Where did you gert this? Near as I can tell, the 1.7.4 for Repoforge one hasn't been published yet, although it's in the pipeline. (I wrote the latest patches to get it to build properly on RHEL 4 and RHEL 5) If you need RPM's, you can use the SRPM tools at https://www.github.com/nkadel/subversoni-1.7.4-srpm/. I'd love to get them into the main codeline's packaging tools to replace the current RPM bundling in trunk. Those really can't deal with the vagaries of the KDE dependence on recent RHEL releases, or the Pythin fun for RHEL 4. In a directory, svn co shows the files that have been > added/modified/deleted. However, the files themselves remain unchanged on > the filesystem. As a workaround, I need to svn export after an svn co in > order for the changes to be made to the filesystem. > > Is this a known issue or am I missing something about svn (a command-line > switch, perhaps?). Permissions appear to be OK as svn export is working. > > Any questions, feel free to ask > > Is this a procedure that worked for you under Subversoin 1.6.x? Can you test it in a parallel system with a subversion 1.6.x update on top of your existing repository?
Re: How to store new password so no need to enter every time?
On Fri, May 4, 2012 at 9:59 AM, Stefan Sperling wrote: > On Fri, May 04, 2012 at 06:48:10AM -0700, frame wrote: > > > > > > On Thursday, May 3, 2012 3:47:13 PM UTC-4, Stefan Sperling wrote: > > > > > > On Thu, May 03, 2012 at 12:41:38PM -0700, frame wrote: > > > > I saw the password is saved in the file within > > > .subversion/auth/svn.simple > > > > directory. Is that correct? How can I have it saved in encrypted > format? > > > Is > > > > this can be achieved by my personal or the system admin group? > > > > > > You would need to configure gnome-keyring or kwallet (see the > > > 'password-stores' option in the 'config' file). I don't know > > > whether those programs are available for your linux distro. > > > They are third-party password encryption tools that Subversion > > > can optionally make use of. > > > > > > Our system admin is against saving password in plain text format. So, I > > have to pursue encryption format way. In my .subversion/config: > > ### Section for configuring external helper applications. > > password-stores = > > > > So 'password-stores' option is empty. We use Red Hat Linux 5.8. Can you > > help more? Thank you. > > I don't know if gnome-keyring or kwallet are available in Red Hat > Linux 5.8, and whether or not support for these features was compiled > into Subversion by the Red Hat packagers. Somebody else on this list > may know. Or you might want to ask Red Hat directly. > > It's in the pipeline over at Repoforge. If you want to jump the gun, take a look at my buildable hooks at http://www.github.com/nkadel/subversion-1.6.18-srpm/ or the 1.7.4 tools there. I'd also very, very strongly recommend updating to RHEL 6 or a free rebuild of that, with these tools already built-in. (I like Scientific Linux these days, for a whole stack of reasons.) If Red Hat 5.8 doesn't ship Subversion with gnome-keyring or kwallet > support, you'll have to type the password or ask your admin to upgrade > to a newer version of Red Hat or use a different Liunx distribution. > Or you might find a build of Subversion for your Red Hat system that > has these features enabled -- a good starting point for your search > would be http://subversion.apache.org/packages.html > See above as well. Now, all that said: I *loathe* HTTP/HTTPS password based acces, because there is no way to prevent your clients form storing passwords locally on Linux or UNIX hosts. They don't *have* to use the kwallet or gnome-keyring tools, and you can't make them without snooping on them all the time. Version 1.6 of Subversion finally started asking before storing them, but earlier versions did not even bother to ask. This is why I'm a strong proponent of svn+ssh access, as supported in many public repositories such as Sourceforge. It prevents the "security is the client's problem" and the "if you don't trust the machine you're working on,, you shouldn't be using it" approaches to security. All we can do is provide these features. If packagers you obtain > Subversion from disable these features or ship outdated versions, > the Subversion project cannot help you. > It's also not feasible to backport them to some still supported operating systems. I can vouch for the difficulties of getting them into RHEL 4, for example, and RHEL 5 wasn't a picnic.
