hi ..

[amit kumar]

hi..

I am getting always an error while installing project from google repositry
..

 Open SVN Repository perspective
- Right click on the left side and go to new -> repository location...
- URL: https://quantdesk.googlecode.com/svn/trunk
- Press Finish
- Open the repository, right click on QuantDesk_UI
- Click Checkout...



i did this ...i
 nstalled..http://subclipse.tigris.org/update_1.6.x   the latest one ...

i am using galileo eclipse ide 3+..

i always get error ...




svn cannot check out .

cannot check out org.tigris.subversion.subclipse.corei am getting this
error in error log .



please help me out ..i tried alot but the same problem always ...

please help..or please send me the proper details of checking out .

Amit

RE: VSS TO SVN Migration Info

[nsnc_eee nsnc_eee]

Thank you Mark for your immediate response.
 
1) Did we require to write any scripts or we can directly we can migrateusing 
the tool?
2) We are going to migrate JAVA code will there be any issues?
 
Regards,
Sabarinath.

--- On Thu, 17/6/10, Cooke, Mark  wrote:


From: Cooke, Mark 
Subject: RE: VSS TO SVN Migration Info
To: users@subversion.apache.org
Cc: "nsnc_eee nsnc_eee" 
Date: Thursday, 17 June, 2010, 7:39 PM


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: older versions of the subversion server

[kmradke]

> 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.

Don't forget this dump/load process will not copy hook scripts and
locked file information.  These will need to be manually copied
from the source repository if needed.

Kevin R.

Re: older versions of the subversion server

[Les Mikesell]

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

RE: older versions of the subversion server

[Thomas Loy]

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 
mailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e>>
To: Thomas Loy 
mailto:thomas%20loy%20%3cthomas@cbeyond.net%3e>>
Cc: Tomoiaga, Alin 
mailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e>>,
 users@subversion.apache.org 
mailto:%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

[Alin]

Ryan and Thomas, 
Thank you very much for your advice.


-Original Message-
From: Ryan Schmidt 
To: Thomas Loy 
Cc: Tomoiaga, Alin , users@subversion.apache.org

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: Recovering repository with multiple missing rev/ files

[Eiren Smith]

On Jun 15, 2010, at 12:20 PM, Eiren Smith wrote:


On Jun 15, 2010, at 12:14 PM, Stefan Sperling wrote:


On Tue, Jun 15, 2010 at 11:49:44AM -0400, Eiren Smith wrote:

Sir:

Thanks for your reply. I'll read those references you cited.



P.S. Other files may also be missing from the revprops/ dir, not
just 7437 -- If I'm willing to lose commit messages, can I live
without some revprops/ files?


You should recreate the revprops for all revisions.


I have emails messages (from SubversionNotify) containing the commit
comments for six of seven of those revisions. If I can rebuild the
repository with some revprops/ files missing, I can edit the
comments later. Will this work?


Sure, that will work. You'll need to do a manual commit of the  
changes
made in lost revisions, and then tweak the revision properties  
after the
commit is done. See also the 'svnadmin setrevprop' command, which  
will
help you to set the revision properties (svn:date, svn:author, and  
svn:log).


Stefan


Thank you.

I won't be able to accurately mimic the seven missing changes as  
most of them were for binary files (project documentation and some  
DLLs).


Instead, is there a way to simply say "All future revisions that  
depend upon these seven revisions are dead/null" so I can piece the  
repo back together with just that minor loss?


Thanks,

/eiren



Anyone:

Any ideas about how to handle this since I can't mimic the changes to  
the binary files modified in the missing revs?


Sorry if nudging this is bad form for this list.

/eiren

Re: older versions of the subversion server

[Ryan Schmidt]

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

[Ryan Schmidt]

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

[Thomas Loy]

We just upgraded from 1.3 to 1.6.x.  Fortunately, we also got new servers for 
the new version, so that helped up.  We upgraded by installing SVN on the new 
servers, exporting our repositories from the old (current production) servers, 
and importing to the new servers.  If you have that option, it worked very well 
for us as we were able to do a dry run of the complete upgrade process.

No, when working with the enterprise’s software repository, you can’t be too 
cautious.  When planning an “in place” upgrade, it would be good to start with 
your current version and work out any issues you find on the upgrade.  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.

Regards,

Tom

From: Alin [mailto:alin.tomoi...@ttu.edu]
Sent: Thursday, June 17, 2010 4:09 PM
To: Ryan Schmidt
Cc: users@subversion.apache.org
Subject: 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 
mailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e>>
To: Tomoiaga, Alin 
mailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e>>
Cc: users@subversion.apache.org 
mailto:%22us...@subversion.apache.org%22%20%3cusers@subversion.apache.org%3e>>
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

[Alin]

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 
To: Tomoiaga, Alin 
Cc: 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: multiple ssh connections

[Jeremy Mordkoff]

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: VSS TO SVN Migration Info

[Cooke, Mark]

Please use < Reply ALL > to keep messages on list (and try not to
top-post)...

>   From: Cooke, Mark 
>   Subject: RE: VSS TO SVN Migration Info
>   To: users@subversion.apache.org
>   Cc: "nsnc_eee nsnc_eee" 
>   Date: Thursday, 17 June, 2010, 7:39 PM
>   
>   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
> 
> -Original Message-
> From: nsnc_eee nsnc_eee [mailto:nsnc...@yahoo.co.in] 
> Sent: 17 June 2010 15:26
> To: Cooke, Mark
> Subject: RE: VSS TO SVN Migration Info
> 
> Thank you Mark for your immediate response.
>  
> 1) Did we require to write any scripts or we can directly we 
> can migrateusing the tool?
>
Check out the website link I sent, there is documentation.

A short summary would be that the tool aims to generate a svn dumpfile
with complete revision history from your archive files which you then
svn import into a fresh repository.

Note: the conversion process can take hours (obviously depending on the
size of your archive).

> 2) We are going to migrate JAVA code will there be any issues?
>  
svn and the tool are fairly agnostic to the file contents so there
should be no JAVA specific issues, only corruption in the VSS
"database"...

~ mark c

RE: VSS TO SVN Migration Info

[Cooke, Mark]

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

VSS TO SVN Migration Info

[nsnc_eee nsnc_eee]

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?
    2) Please give me the best migration tool that suites VSS to SVN 
Migartion with revison History?
    3) Will Subversion is configurable with Eclipse easily?
 
 
Thanks in Advance.
 
Regards,
Sabarinath.


 

Re: Applying multiple commits done to a branch to another branch

[Andy Levy]

On Thu, Jun 17, 2010 at 05:38, emerson  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  wrote:
>> On Thu, Jun 17, 2010 at 4:20 AM, Bob Archer  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: Applying multiple commits done to a branch to another branch

[emerson]

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.

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?

thanks
emerson

On 16 June 2010 22:40, Daniel Becroft  wrote:
> On Thu, Jun 17, 2010 at 4:20 AM, Bob Archer  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: svn move directory will create a new revision for every file inside this directory?

[Ullrich.Jans]

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.