ISVNAuthenticationProvider authenticationProvider
Hello, having a ISVNAuthenticationProvider authenticationProvider, how can get user name and password for accessing a Subversion repository ? Thank you. Michael
relocate and dump/load
Hello, does a svn relocate in a workspace work when I'm migrating to a different server *and* dump/load the old repo into a new repository, on the new server? What's the recommended strategy to keep a workspace in sync after a server migration and dump/load. Is it best to just checkout everything again from the new repo? Thanks. Michael
Re: relocate and dump/load
Hello Uli, thanks. The new target repository has content already. With other words: they dumped content (that has to be loaded) will get other revision numbers once loaded into the new repo. In this case, does a relocate work if I just change the UUID in the dump file to the UUID of the new repository? The content of the dump file is not modified. It will be loaded as-is. Thanks! Regards/Gruß zurück! Michael Am 22.08.2012 12:29, schrieb Michael Hüttermann: does a svn relocate in a workspace work when I'm migrating to a different server *and* dump/load the old repo into a new repository, on the new server? svn relocate tells the working copy that the identical repository is to be accessed via a different URL from now on. The important part there is the word identical, which refers to the repo's ID. When loading an empty repository from a dumpfile, the default is to take the ID from the dumpfile, otherwise the ID generated by svnadmin create is preserved. Of course, even if the repositories have the same ID, if they have different contents (like different revision history) it will still break things. For your case, it works if the new repository 1. has the same ID, preserve that while loading 2. has equivalent content, don't modify the dump file BTW: SVN is not a magic backup tool, it can't save you from hardware failure. Your backup/recovery plan should include the answers to the above already! Schoene Gruesse aus Hamburg! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
automatically resolve (some) tree conflicts
Hello, nailing down some tree conflicts show that there are no differences at all comparing merged versions. One example is a file that has the same name, path and content, but was removed/added meanwhile, and Subversion lost the tracking that it is exactly the same file than before. Is there a tool or command to automatically resolve such sort of tree conflicts? Thank you. Regards Michael
automatically resolve (some) tree conflicts
Hello, nailing down some tree conflicts show that there are no differences at all comparing merged versions. One example is a file that has the same name, path and content, but was removed/added meanwhile, and Subversion lost the tracking that it is exactly the same file than before. Is there a tool or command to automatically resolve such sort of tree conflicts? Thank you. Regards Michael
Re: preventing commits (this is *not* a classic hook question)
Hi David, thanks, that's awesome! Michael I have a pre-commit hook that stores its configuration inside your repository. You'll need access to the Subversion server to set it up, but once it's setup, you can control access by checking out the control file from the repository, making your changes, and then checking it back in. This is a modification of a hook that I've been using for years. Originally, the control file was kept on the server -- usually inside the hooks directory. However, that meant logging onto the server, and that was getting too difficult to do all the time. Besides, this way, I can track who changed the control file and why. What prevents anyone from changing the control file? The control file is configured, so only the administrators can modify it. You can take a look at it at https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook. (Yes, a Subversion hook is stored in GitHub). If you need any further help, contact me at da...@weintraub.name, and I'll see what I can do. -- David Weintraub qazw...@gmail.com
RE: preventing commits (this is *not* a classic hook question)
Hello Bob, Nico, Les, thanks for your pointers. Great help, exactly what I've looked for. Thanks!! Michael Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. Create a project in your repository that contains a config file of some type. Give write access to this path only to those people that you want to be able to enable/disable checkins. Create a working copy of said config project and check it out on your svn server. Have your hook script update the working copy (or perhaps have a cron job that updates this wc every 60 seconds or whatever) and read this config file to determine if commits are allowed. All the users will have to do is edit the config file and commit it. BOb A poor man's option could be working with locks. But, recursively locking a large repo path could be inefficient, and locks can be stolen anyway. So it looks like the wrong approach from many perspectives. Any idea for preventing commits, for a specific time, without being able to directly accessing the hooks folder? If the access is through svn+ssh and you can be granted access to the authorized_keys, you can tweak it to read-only. If it's an Apache based access with HTTPS, you can manipulate the Apache config (which requires reloading the Apache server configuration, or control of a .htaccess file) Means vary depending on which technology you use and what you *do* have access to.
preventing commits (this is *not* a classic hook question)
Hello, I'm wondering if there is any strategy for temporary preventing people from committing to a svn repository, without the person who sets the hook (or sth similar) being the admin of the svn repository. Thus, in this case, there is no option to directly access the /hooks/ folder. A poor man's option could be working with locks. But, recursively locking a large repo path could be inefficient, and locks can be stolen anyway. So it looks like the wrong approach from many perspectives. Any idea for preventing commits, for a specific time, without being able to directly accessing the hooks folder? Thanks!!! Michael
the revision number and a tag
Hello, given a Subversion tag, what's the best way to get the revision number of that tag, i.e. the revision number with which the tag was created? Is it possible at all having checked out the tag to a local working copy? Or is there any other way to cross-reference a tag to a revision number? Thanks. Michael
