I'm migrating from a HD to an SSD. I was using TortoiseSVN 1.7 on the HD for a project that has multiple coders using the same repository.
I installed TSVN 1.8 on the SSD, and am attempting to use it with the project's old-format working copy. It asks me to upgrade the format to 1.8, but I'm wondering if that permanent change is going to make its way back into the repository when I do my next checkin, and if that is going to cause problems for other coders not using the new format.
Thank you.
No. Internal local changes of WC structure doesn't reflected in remote repository: there are only a few compatibility issues between server- and client-side versions of SVN
LazyBadger is correct but a few more details are worth noting:
Be aware of the distinction of the SVN server vs the SVN client; TSVN is a client, existing separately on the machine of each developer. Thus, this question is addressing upgrading a client specifically.
When it asks you to upgrade the format to 1.8, it is talking about the infrastructure of your working copy, the way it stores and manages files on your box. That infrastructure is local to your machine; it is not reflected on the server.
However, it is not a general rule that you can always upgrade a client and remain compatible, but moving from TSVN 1.7 to TSVN 1.8 does, in fact, maintain compatibility.
Ultimately to answer this question each time you are considering an upgrade, have a look at the TortoiseSVN release notes--for 1.8 they are here. In there you will see that it specifically states that "Older clients and servers interoperate transparently with 1.8 servers and clients."
Related
I customize Linux (RHEL) Operating Systems releases for specific platforms/customers, etc... (and windows). We do kickstart installs, customize the branding, install specific packages, customize partitioning, etc...
I need suggestions on better ways to version control these OS's. Currently, we use SVN to Control the base installs (i.e. RHEL 5.6, 6.1, etc...) We don't upload the base RPMS to the Subversion server as they bloat the repo quick, only custom elements. We have YUM repos for each of the versions. A script gets run after checking out the base OS version which then performs a grab from the YUM repo for the specific package versions needed. I have been unable to find any other posts/guides doing exactly what I need to do.
We basically have to version control the package list for each OS release and do goofy things to get the packages into the base OS to create the final OS image which then gets installed via kickstart (different process for windows).
I find this cumbersome and leads to potential errors. There must be a better way! I've looked into an Artifact Repository for the non-modified components but not sure if this will significantly help me.
PS: Version control for each custom release is critical, I can't even just say RHEL 6.2 is RHEL 6.2, I have to be able to prove the custom release is the correct custom release somehow (as SVN would do).
ANY suggestions are appreciated!
Have you considered using Pulp? You can create a repository for each "release" that you want to track.
Hi I have a Windows OS and I currently have the most up to date version of Node.JS running (which includes npm). I would really like build and compile 0.1.91 which can be found here http://nodejs.org/dist/. I'm extremely new to this and any all help would be greatly appreciated.
Node first supported native Windows builds in the .5 dev branch. To make it happen, they had to rewrite many internals from scratch – the platform compatibility layer now exists as libuv.
Before that, you had to build Node under Cygwin. I remember building .4 in Windows with Cygwin, and it was a complete pain. The GitHub wiki has since pulled down all Cygwin-related information since it's no longer relevant. (If you really want to see how Cygwin builds were done, I suppose you could clone the wiki's repo and go digging around. The information isn't available online anymore.)
Support for building on Windows with Cygwin wasn't added until 0.1.98, and support was dropped with .6. So, the specific version you're trying to build won't work.
At any rate, it's a very bad idea to run very old software, especially something like Node 0.1, which was still very early in its development. It's nearly guaranteed to be full of security holes.
Today, our Enterprise Architect mentioned that a recent vulnerability was discovered in the JRE 1.7. I found an article the JRE 1.7 vulnerability recommending disabling Java.
I am running JDK 1.5 and 1.6 at work (like many organizations, we're not on the latest of technologies), so no problems there.
At home I am doing development with Java SE 7u6. I'm playing with Grails, Spring Security, trying to keep learning.
I have already gone and disabled the Java Plug-in in all my browsers on my home development machine. However, does anyone know if my home dev machine is still vulnerable by virtue of having the JDK 7 installed? I did find this article on US-CERT declaring the vulnerability notice: Oracle Java JRE 1.7 Expression.execute() fails to restrict access to privileged code.
It sounded like as long as the browser is not able to run Applets, I should be fine (it should not with the Java Plug-in disabled). However, what about Java Web Start/JNLP? Could that get invoked? That's the only other thing I could think of, other than Applets, that might be of concern.
Just wondering if I need to go through the efforts of uninstalling my Java SE 7 and dropping back to a JDK6.
What have others done upon learning of this security issue with JRE 1.7?
The details of the latest vulnerability have not been made public. However, my understanding is that it only affects Java browser plugins. The recommended mitigation is to disable the Java browser plugins. No mention is made of non-plugin Java, so I think it is safe to assume that your dev machine is not vulnerable simply by virtue of having Java 7 installed.
However, what about Java Web Start/JNLP? Could that get invoked?
I don't think so. I think it is safe to assume that the people who found the problem would have thought of that potential attack vector. (But simple common sense says that you wouldn't want to be launching random JNLP programs in the first place ...)
I understand it as if you have to visit a malicious site to become infected. So no, you are not at risk simply by virtue of having Java 7 installed in your browser.
Some useful links:
US-CERT link which explains the vulnerability:
http://www.kb.cert.org/vuls/id/636312
Oracle link to their Security Alerts (not just Java, but also including Java):
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
As of writing (30 Aug 2012) I cannot see that Oracle has yet issued an alert for this. I can't really figure out if they only issue such alerts AFTER a patch has been created. According to US-CERT site Oracle was officially alerted on 29 Aug 2012 but they may already have known about it because blog reports about the vulnerability started a few days before the 29th.
What you can read on the Oracle site is that the next planned "Java SE Critical Patch Update" is on 16 October 2012. Surely they won't wait for that but release an out-of-band patch for this vulnerability asap. (they've done so before)
I have just upgraded to SVN 1.7.1 and I have had nothing but problems trying to get my netbeans and everything else to work with it. I have tried 'svn upgrade' but I get an error which is as follows:
C:\wamp\Projects>svn upgrade BMPortal
svn: E155019: Can't upgrade 'C:\wamp\Projects\BMPortal' as it is not a
pre-1.7 working copy directory
svn: E150000: Missing default entry
Could anyone suggest a way to fix this. The reason why I am trying to upgrade is because my netbeans says:
The Path 'C:\wamp\Projects\BMPortal' appears to be part of a
Subversion 1.7 or greater working copy. Please upgrade your Subversion
client to use this working copy.
As I have upgraded my SVN Client to 1.7, I don't know why it is still moaning at me.
Just FYI:
The SVN Server is on an Arch Linux box running UberSVN.
The client (my computer) is Windows 7 64bit.
I actually had the very same problem (or at least the same error message!).
After trying everything you have said earlier and not getting any results, I realise that I had copied some files to the project that contains svn files from an older (1.6) version. I delete the 1.6 folders and the everything worked fine again.
I hope this could help some other people too!
Best regards,
Andrés
Your Netbeans installation seems to use another SVN-Client as the one when you type svn on the console.
So you have to upgrade your Netbeans-Subversion plugin too.
Sorry to waste your time guys, I have finally found a work around for this, http://netbeans.org/projects/versioncontrol/pages/Subversion1_7
But thanks again all the same! It's much appreciated!
SVN v1.7.0 and above uses a new working copy file format, so you need to upgrade your working copy to the new format. If you right-click the folder in Windows Explorer, the TortoiseSVN context menu items should show only "SVN Upgrade working copy" - click that to upgrade it.
Warning: If you use any other SVN apps as well as TortoiseSVN on the same PC, they may not work with the new working copy file format.
It's worth upgrading in my opinion though - must faster, better merging, better dialogs and error reporting, etc!
I have a branch checked out in Tortoise 1.4.2, edited it in 1.6.2 and now can't modify it on my old machine running 1.4.2. The latest version on the Tortoise website is 1.6.7. Are versions 1.6.x interoperable? I'm stuck with version 1.6.2 on my new machine.
Basically, a basic principle with SVN is that :
When you have a working copy in 1.4.x and you use a 1.6.x tool to work on it, it'll automatically be converted to 1.6.x
Which means you will not be able to work with your 1.4.x tool anymore
Between 1.6.x and 1.6.y, I've never seen any problem.
Tortoise SVNuses the Subversion libraries underneath, and the first two parts of Tortoise's version numbers match up with the version of the Subversion libraries, so Tortoise SVN versionion1.6.x will use the Subversion client libraries version 1.6.y.
The Subversion team often changes the working copy format between minor releases (1.5.x -> 1.6.x) but try hard not to break compatibility between patch releases (1.6.2 -> 1.6.3). Newer versions can read old working copies, but only to immediately upgrade them.
So the answer to your question is "Yes".