RE: svn move directory will create a new revision for every file inside this directory?
Hi, -Original Message- From: Leonardo Azize Martins [mailto:laz...@gmail.com] Sent: Friday, June 11, 2010 2:16 PM To: Bob Archer Cc: users@subversion.apache.org Subject: Re: svn move directory will create a new revision for every file inside this directory? Hi Bob, You have already answered my question. It does not create a new revision for files inside directory that was moved. Actually, when you check out a fresh working copy, you should see that all files are at the same revision (4, in this case). So, if I want to get FILE_A in REV 2 from path /DIR_B/DIR_A/FILE_A, I must use PEGREV 4 I'm not quite getting what you're trying to do. You should be able to tell svn that you want this file, as it was in rev. 2 - it should automatically follow the trail back and hand you the correct state. Best regards, Ullrich Jans -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Otto Fößel, Jarkko Sairanen Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Re: Applying multiple commits done to a branch to another branch
On Thu, Jun 17, 2010 at 05:38, emerson echofloripa.y...@gmail.com wrote: Hi Guys Thanks for the answers. First Andy, yes, we put more than the story code on the commits :) We are using svn 1.4.4 ont he server, so to be able to keep track of the ancestors logs we will probably need to upgrade. Note that the 1.4 series has not been supported for quite some time, and when 1.7 is released, 1.5 support will be dropped. You definitely ought to upgrade. Still, I believe we need some tool to search the logs for that especific # code of the story. Correct me if I am wrong, but from there I would have to collect all the revision numbers, and apply them in a single merge manually? Is there any way to automate this? If each story gets its own branch, then you don't have to worry about that. On 16 June 2010 22:40, Daniel Becroft djcbecr...@gmail.com wrote: On Thu, Jun 17, 2010 at 4:20 AM, Bob Archer bob.arc...@amsi.com wrote: You're describing a normal usage of merging. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html You don't want to redo all those commit messages, you want the merge to be aware of the history behind everything that's been done (which, if you're using 1.5 or later, is taken care of), so that svn log can trace back all those messages fall right in line. Really... I didn't know this happened. If you look at the log of trunk where you have merged in from branch won't it only show the merge as a single rev with the message you made in the merge commit. How will you be able to trace the log back through the changes made in branch? It does, but not by default. You need to use the '-g/--use-merge-history' switch. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.logblame Cheers, Daniel B.
RE: VSS TO SVN Migration Info
Hello, From: nsnc_eee nsnc_eee [mailto:nsnc...@yahoo.co.in] Sent: 17 June 2010 14:07 Subject: VSS TO SVN Migration Info Hi, This is Sabrinath, i am working as a Build And Release Engineer. I recently joined in other Company where they are using VSS as Source Code repository and i'm new to this. In my prev company we used SVN and i am satisfied with the SVN and its Features. I am planing to Migrate the Source code from VSS to SVN, i had few Q's regd this. 1) Is this safe to use Migration Tools to Migrate Source code from VSS to SVN with revison history? I have done this recently using a tool. While there may well be issues in the VSS archive that cause problems (mostly orphaned files), we have managed to convert all archives so far. 2) Please give me the best migration tool that suites VSS to SVN Migartion with revison History? I recommend you check out http://code.google.com/p/vss2svn/ This one works directly against the VSS files without requiring a VSS client and bunches file commits into svn revisions based on a time window (i.e. all updates within a few seconds are probably related). 3) Will Subversion is configurable with Eclipse easily? Check out subclipse, here's a thread at stack overflow: http://stackoverflow.com/questions/61320/svn-plugins-for-eclipse-subclip se-vs-subversive Good luck, ~ mark c
RE: multiple ssh connections
Another option is to establish a single SSH session using port mapping and then run all of your SVN traffic across that. Something like ssh -L 3690:svn_server:3690 ssh_server svn svn://localhost/ The first line says take any traffic destined for the svn port on my machine and send it to the svn port on the svn server at the other end of an SSH tunnel. The second line says pretend my svn server is local JLm
Re: older versions of the subversion server
That is a very good question. Our subversion server has not been updated in a while and it is still on version 1.4.2. I was looking into updating it to take advantage of the new merge tracking features (among others). Since we are using such an old version, I wanted to replicate our production environment on a test server (thus requiring version 1.4.2) and performing the upgrade there first. Do you think I am being overly cautious? What are the chances for a problem to occur in the upgrade process? Thank you, Alin -Original Message- From: Ryan Schmidt subversion-20...@ryandesign.com To: Tomoiaga, Alin alin.tomoi...@ttu.edu Cc: users@subversion.apache.org users@subversion.apache.org Subject: Re: older versions of the subversion server Date: Wed, 16 Jun 2010 16:13:32 -0500 On Jun 16, 2010, at 11:11, Alin wrote: I am trying to install an older version of subversion (1.4.2) on two Linux systems Ubuntu and Red Hat ( 2.6.31-20-generic Ubuntu and 2.6.18-164.el5 ) and I am having a hard time locating the older version packages for subversion. I tried both the Ubuntu and Red Hat repositories and the subversion website. Can you please tell me if these packages are still available for download? Certainly the source is still available from the Subversion project's web site. Not sure where you'd get older precompiled packages for various OSes. Note that Subversion 1.4.x and earlier are unsupported by now, and when 1.7.0 comes out, support for 1.5.x will be dropped. Why do you need to use such an old version?
Re: older versions of the subversion server
On Jun 17, 2010, at 15:09, Alin wrote: Note that Subversion 1.4.x and earlier are unsupported by now, and when 1.7.0 comes out, support for 1.5.x will be dropped. Why do you need to use such an old version? That is a very good question. Our subversion server has not been updated in a while and it is still on version 1.4.2. I was looking into updating it to take advantage of the new merge tracking features (among others). Since we are using such an old version, I wanted to replicate our production environment on a test server (thus requiring version 1.4.2) and performing the upgrade there first. Ah, ok. Do you think I am being overly cautious? What are the chances for a problem to occur in the upgrade process? It would probably be sufficient to install Subversion 1.6.x on the test server, and copy your repository from the production server to the test server. Then test your upgrade strategy. One good way to copy the repository would be to svnadmin dump on the production server and svnadmin load on the test server. This would automatically upgrade the repository to the latest most efficient format.
RE: older versions of the subversion server
No problem. That was a good tip from Ryan on the start-commit hook. I wish I had know about it, although we did publicize to our users well in advance that they needed to upgrade and they could do it anytime before we did our server upgrade. I really only got one call from a user and he was and Eclipse user. Regards, Tom From: Alin [mailto:alin.tomoi...@ttu.edu] Sent: Thursday, June 17, 2010 4:29 PM To: Ryan Schmidt; Thomas Loy Cc: users@subversion.apache.org Subject: Re: older versions of the subversion server Ryan and Thomas, Thank you very much for your advice. -Original Message- From: Ryan Schmidt subversion-20...@ryandesign.commailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e To: Thomas Loy thomas@cbeyond.netmailto:thomas%20loy%20%3cthomas@cbeyond.net%3e Cc: Tomoiaga, Alin alin.tomoi...@ttu.edumailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e, users@subversion.apache.org users@subversion.apache.orgmailto:%22us...@subversion.apache.org%22%20%3cusers@subversion.apache.org%3e Subject: Re: older versions of the subversion server Date: Thu, 17 Jun 2010 15:24:56 -0500 On Jun 17, 2010, at 15:18, Thomas Loy wrote: On the bright side, we had virtually no issues on our upgrade – the major issue was trying to get all of our users to upgrade their clients. There is at least a way you can automate advising your users to upgrade to Subverison 1.5 or later if they have 1.4.x or earlier: the start-commit hook script. This hook script will be passed a list of client capabilities; if the client capabilities do not include mergeinfo, you know it's older than 1.5. You could at that point abort the commit and print an error message advising the user to upgrade their client. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html I don't know of a way to detect the client version beyond that, though. And unfortunately early versions of 1.5.x weren't totally satisfactory for merge tracking, so you really do want your clients to be the latest version.
Re: older versions of the subversion server
On 6/17/2010 3:09 PM, Alin wrote: That is a very good question. Our subversion server has not been updated in a while and it is still on version 1.4.2. I was looking into updating it to take advantage of the new merge tracking features (among others). Since we are using such an old version, I wanted to replicate our production environment on a test server (thus requiring version 1.4.2) and performing the upgrade there first. 1.4.2 is still in the CentOS 5.x base and installable by yum - and that should mean that RHEL has the same if you are looking for rpms. Do you think I am being overly cautious? What are the chances for a problem to occur in the upgrade process? I wouldn't expect problems - or for you to learn much from a test copy. What you really need is to make sure you can put things back on the real server regardless of anything that happens. That means you'll need snapshots of the repository(ies) made with the server stopped and copies of the programs and any local configuration - just in case... Also, note that when you first use a new client version it will modify any working copies it touches so that older versions can't be used again. Differing versions of clients and servers will interoperate but you don't get all the new features until both are new. -- Les Mikesell lesmikes...@gmail.com
