?????? Subversion Exception!
Files and directories names are correct. This problem appears only once. In the show log dialog click on the menu 'get merge logs' for a file.this error occurred.
Re: WebDAV support in future versions of SVN server?
On Tue, Jun 25, 2013 at 9:55 AM, Thomas Harold thomas-li...@nybeta.com wrote: Is it still a long-term goal to maintain the ability to mount a SVN repository as a WebDAV folder? Out of curiosity, why do you feel the need for this? Working in a remote copy isn't enough for your uses?
Re: Regarding the Voilation exception while creating the workspace
Hi, I replaced svn version to the 1.7.10 and still facing same issue while creating the work space. * fix crash with --username option on Windows (r1396285). please could u explain clearly about this am not getting this. On Fri, Jun 21, 2013 at 2:43 AM, Johan Corveleyn jcor...@gmail.com wrote: That's a known issue that was only present in 1.7.7 on Windows (crash with --username option in combination with cached credentials on Windows). You should upgrade your svn client to at least 1.7.8. -- Johan On Thu, Jun 20, 2013 at 7:48 PM, Amar Kumar Banda aba...@nisum.com wrote: Hi, Please could you go through the below files and give the solution, am unable to create the workspace for nwms. -- Thank You! Best Regards, AMARKUMAR BANDA -- *Thank You!* *Best Regards,* *AMARKUMAR BANDA*
Re: Regarding the Voilation exception while creating the workspace
Guten Tag Amar Kumar Banda, am Mittwoch, 26. Juni 2013 um 14:55 schrieben Sie: I replaced svn version to the 1.7.10 and still facing same issue while creating the work space. * fix crash with --username option on Windows (r1396285). please could u explain clearly about this am not getting this. This workaround is not necessary anymore in 1.7.10 and beyond, if you really get the exact same error you either don't use the new svn version, because of other older versions in the path for example, or you simply don't get the exact same, but some other error now. 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...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Question about subversion
Hi there. I have a question about subversion. I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why. Files who should not be on SVN : * files automatically generated * files containing specific information about my development environment (so properties files for example) * executable files PS: I am conscious that we can put anything to subversion but I am looking for Best practices Thank you so much * Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel. **
Re: Question about subversion
Guten Tag Marc Davenne, am Mittwoch, 26. Juni 2013 um 16:36 schrieben Sie: Files who should not be on SVN : files automatically generated This depends on the files which get automatically generated and their purpose: It's perfectly valid to version automatically generated class stubs e.g. for web service clients and servers which get manually changed afterwards or simply to make sure that one generated version stays exactly the same and doesn't use new interface names, automatically generated GUID or whatever those tools out there implemented. files containing specific information about my development environment (so properties files for example) Depends again, it's perfectly valid to version project files of Eclipse, Visual Studio or whatever you use to assure that every member of you project use the same settings etc. executable files Depends again?! ;-) There a some projects out there which version executables, MSI packages and stuff like that and provide direct download access to their customers using some web application like ViewVC or WebSVN. If you have an environment were your executables are not build automatically using some kind of CI, Hudson, Jenkins, whatever, versioning manually build and once tested applications can save a lot of time. Besides that, one may be in an situation were one has only access to third party, pre compiled libraries in which case there may be no reason to not version those, too. 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...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: WebDAV support in future versions of SVN server?
On 6/26/2013 8:15 AM, Nico Kadel-Garcia wrote: On Tue, Jun 25, 2013 at 9:55 AM, Thomas Harold thomas-li...@nybeta.com wrote: Is it still a long-term goal to maintain the ability to mount a SVN repository as a WebDAV folder? Out of curiosity, why do you feel the need for this? Working in a remote copy isn't enough for your uses? Less technical users like the idea of being able to treat the SVN repository as a mapped drive where everything is auto-versioned.
RE: Question about subversion
Hi there. I have a question about subversion. I think the previous response was quite correct, it mostly all depends. I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why. Files who should not be on SVN : . files automatically generated Well, Visual Studio generates designer files when you edit a web form... we do check those in. We also use compass and I check in the compiled .css file. Of course, I would like to no longer do that and have the build server generate it. . files containing specific information about my development environment (so properties files for example) For the most part, yes. We check in the files with a .template in the name and have an init.bat file that copies them out... this way for any initial checkout you at least get reasonable defaults. Our template files also contain the QA connection strings so even a dev without the dbs set up will be able to locally run the ap. (as was said before, it depends). . executable files PS: I am conscious that we can put anything to subversion but I am looking for Best practices Thank you so much Once again, it depends. Many people feel it is a best practice to be able to do a check-out and then build the file without having to do any specific tool installs on your PC. Stuff like NuGet (gems npm whatever) help a lot, since your build can leverage those tools to get the binaries you need to build test. But, sometimes those tools need to be there. For example, we have nant (build tool) and mbunit (test tool) checked in so that the build server doesn't need to have each of those tools installed, and so also we can rev those tools by project rather than having to upgrade all the projects at once. Also, we have some legacy VB6 code in our project and we use binary compatibility, so we need to DLLs checked in. As much as I don't like it. I am also considering moving these to a new repo and linking with external so that we don't get all the repo bloat... I can just blow away the binary repo every year or so. But, yes, for the most part, that artifacts that your project builds aren't checked in.. but sometimes dependencies and tools are checked in as binaries. So the correct answer, as with almost anything in development is, it depends. BOb * Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel. **
Re: vimdiff wrapper for diff-cmd not working with 1.8
On Jun 21, 2013, at 15:23 , Philip Martin wrote: Another user raised the issue http://subversion.tigris.org/issues/show_bug.cgi?id=4382 Using '--diff-cmd colordiff' to get coloured output no longer works. Here's a solution that requires the user to mark the command as requiring direct access. Log and patch: Allow the user to bypass the temporary spool file when invoking an external diff command. This allows commands that expect to see a terminal to work. The user adds the prefix 'svn:direct:' to the command and Subversion passes the stream's file rather than creating a spool file. So --diff-cmd foo runs foo with a spool file and --diff-cmd svn:direct:foo runs foo with the stream's file. I can confirm that your patch works for me (OS X Lion and Linux). Thanks for the quick fix! Keeping my fingers crossed that this will make it into the repository soon. Michael smime.p7s Description: S/MIME cryptographic signature
RE: Question about subversion
From: Marc Davenne [mailto:marc.dave...@cramif.cnamts.fr] Sent: Wednesday, June 26, 2013 10:37 AM To: users@subversion.apache.org Subject: Question about subversion Hi there. I have a question about subversion. I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why. Files who should not be on SVN : * files automatically generated * files containing specific information about my development environment (so properties files for example) * executable files PS: I am conscious that we can put anything to subversion but I am looking for Best practices Thank you so much Wrong question. The correct question is: Do I have what I need to reproduce the build? Generally speaking: * The reasons to avoid checking in generated files are: - they can be re-created automatically, - checking them in results in duplicate data which - takes up space unnecessarily - leads to data synchronization issues, i.e. are the generated files I checked in, the same as the files the build generates? And before you say that's a stupid thing to worry about, ask yourself what happens when a checked in generated file is no longer generated by the build? (Someone will have to manually delete the no longer needed generated file from the repo.) * The reason to avoid checking in dev environment files is because they're different between everyone's work environment and provide no value to the build process. * The reasons to avoid checking in executable files are: - they're big - they can't be merged, and/or - the executable is generated by the build and thus can be re-built from code if necessary. However, as others have noted, there are times when you want to check in such files. They're guidelines, not hard and fast rules. Guidelines/Rules exist to support your goals. Your goals are build reproducibility, accurate deployments, and other SCM-ish things that allow your organization to deliver a product that customers will pay money for so that your company can pay your salary. Craft your guidelines/rules in that context and you'll be fine.
svn: E175009: XML parsing failed: (400 Bad Request) after upgrade to 1.8
Since upgrading to Subversion 1.8.0 (r1490375) a few days ago, I have been unable to checkout (or update, after upgrading my working copy) a particular repository (http://www.sharedproteomics.com/OMSSA/svn). I get the error: svn: E175009: XML parsing failed: (400 Bad Request) This is somehow related to my network configuration, as I get this problem from work but not from home. At least one other person seems to be experiencing this problem ( http://comments.gmane.org/gmane.comp.version-control.subversion.user/113693 ). Should I file a new issue? -Craig
Re: svn: E175009: XML parsing failed: (400 Bad Request) after upgrade to 1.8
On Wed, Jun 26, 2013 at 10:44 PM, Craig Wenger craig.wen...@gmail.com wrote: Since upgrading to Subversion 1.8.0 (r1490375) a few days ago, I have been unable to checkout (or update, after upgrading my working copy) a particular repository (http://www.sharedproteomics.com/OMSSA/svn). I get the error: svn: E175009: XML parsing failed: (400 Bad Request) This is somehow related to my network configuration, as I get this problem from work but not from home. At least one other person seems to be experiencing this problem (http://comments.gmane.org/gmane.comp.version-control.subversion.user/113693). Should I file a new issue? Can you figure out what the difference in network configuration is? A proxy perhaps? Can you find out which proxy? It would probably be interesting if you could get a wiretrace of what's going on. I think you should file an issue (referring to this thread), and try to provide as much information as possible. Thanks, -- Johan
Re: Question about subversion
2013/6/26 Marc Davenne marc.dave...@cramif.cnamts.fr: Hi there. I have a question about subversion. I have a theory on what files should not be on SVN and I would like you to tell me if you agree. If you dont agree can you tell me why please. If you see more files that should not be there, tell me and why. Files who should not be on SVN : files automatically generated files containing specific information about my development environment (so properties files for example) executable files PS: I am conscious that we can put anything to subversion but I am looking for Best practices Thank you so much Files that should not be on SVN is like food that should not be in a restaurant. It depends tremendously on your purposes. For example, a tag with locked down binaries, or installable packages, can be very useful for controlling what binaries are deployed in some environments. They're not efficient to store, however, and if there is a lot of churn of testable or development binaries, the record of them can get out of hand. It can be very efficient for a source tree for building software to avoid .o files, .a files, and other geneerated compilation productions that are not part of hte source code itself. But I know plenty of Subversion and other source control systems where developers store the .jar files from java, or store critical binaries for full software deployments. Perhaps you can describe your use case? That affects best practices profoundly.
