Re: restored deleted data on subversion

[Arpad Ilia]

> On 11/08/2010 10:35 PM, Campbell Allan wrote:
> > On Monday 08 Nov 2010, wrodrigues201 wrote:
> >> Hello,
> >> 
> >> Our subversion (1.4.3-r23084 on windows 2003) was holding around 1.6 TB
> >> of data and one user has accidentally deleted a directory of 1 TB. I
> >> have done a svn export from the previous version and have the data. Do I
> >> have to add and again commit this data ? Will it use up 1 TB of disk
> >> space on the svn server ? Is there any way i can restore the data from
> >> the previous version without using up 1 TB of disk space ?
> >> 
> >> Thanks in advance.
> >> 
> >> wrodrigues
> > 
> > If I understand correctly, nothing has been deleted from the server it
> > just isn't anymore in the working copy? If that is the case then
> > assuming it wasn't too long ago or you do not mind redoing/merging the
> > commits then you could take a copy of the trunk/branch prior to the
> > delete and rename this back. The delete would still have occurred but on
> > the branch that no longer matters and once you're happy that can be
> > deleted too. This will only take up the space required for a few copies
> > of the parent, nowhere near the 1TB of the content. Something like
> > 
> > svn copy https://svnserver/svn/project/tr...@12345 \
> > 
> >   https://svnserver/svn/project/trunkcopy
> > 
> > svn move https://svnserver/svn/project/trunk \
> > 
> >   https://svnserver/svn/project/trunkold
> > 
> > svn move https://svnserver/svn/project/trunkcopy \
> > 
> >   https://svnserver/svn/project/trunk

Wouldn't have it been easier to just simply reverse merge the changeset that 
deleted the directory? E.g. (in an up to date a working copy)

svn merge -r 12345:12344 https://svnserver/svn/project/trunk

This should remove the r12345 changeset. Or did I miss something?


iarpad

> 
> Hello Allan,
> 
> Thanks your suggestions worked like a charm.

Problem with diff after merging

[Jahn Otto Andersen]

I am using a code review tool called ReviewBoard to do code reviews. This
tool uses svn diff to report the changes between BASE and work area.

 

I'm having problems when working in a branch and then merging into trunk.
This problem seems to be caused by the diff generated by svn diff.

 

What I do: 

1. Create a new branch based on trunk using TortoiseSVN's "branch" function
2. Commit several changes into the branch, including creating new files 
3. Reintegrate branch into trunk using TortoiseSVN's "reintegrate branch"
function.
4. Generate the diff using svn diff and use this for the code review 

The problem is:

The diff that is created by svn diff does not contain the new file. The diff
file contains the following lines (given that the new file is named
NewFile.cs): 

 

 
Property changes on: NewFile.cs 
___ 
Modified: svn:mergeinfo 
   Merged /blabla/branches/mybranch/NewFile.cs:r11226-11336 
-

 

It seems like the diff contains information about the fact that the new file
is being merged into trunk from the branch, but it doesn't contain the
actual lines in the new file. As a result, the review request in ReviewBoard
doesn't contain NewFile.cs at all. 

Is there any way I can make svn diff include the new lines in the new file?

 

SVN Migration from VSS

[Neson Maxmelbin (RBEI/EMT5)]

Hello ,

I did a migrate of a project from VSS to SVN using the migrate.pl from 
http://neilsleightholm.blogspot.com/2007/08/migrating-from-visual-source-safe-to.html
 .

Migration was ok . But I cant see the VSS labels been migrated?
Is there a way to migrate the VSS labels also to some form in SVN?

Thanks and Regards
Maxmelbin Neson
-
Robert Bosch Engineering and Business Solutions Limited
Engineering Services - Methods and Tools (RBEI/EMT5)
123 Industrial Layout  -  Hosur Road -  Bangalore 560 095  -  INDIA
Telephone: +91 80 6657-4743  Fax: +91 80 6657-1404
VOIP : +49(711)811-3605399
maxmelbin.ne...@in.bosch.com
www.bosch.com

Re: SVN Migration from VSS

[Ulrich Eckhardt]

On Monday 15 November 2010, Neson Maxmelbin (RBEI/EMT5) wrote:
> I did a migrate of a project from VSS to SVN using the migrate.pl from
> http://neilsleightholm.blogspot.com/2007/08/migrating-from-visual-source-sa
>fe-to.html .
>
> Migration was ok . But I cant see the VSS labels been migrated?
> Is there a way to migrate the VSS labels also to some form in SVN?

There was a different project, vss2svn, which aimed at achieving the same. 
Both projects are not part of Subversion itself though, and at least vss2svn 
has a separate mailinglist.

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
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. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: SVN Migration from VSS

[David Weintraub]

On Mon, Nov 15, 2010 at 7:28 AM, Neson Maxmelbin (RBEI/EMT5)
 wrote:
>
> I did a migrate of a project from VSS to SVN using the migrate.pl from
> http://neilsleightholm.blogspot.com/2007/08/migrating-from-visual-source-safe-to.html
> .
>
> Migration was ok . But I cant see the VSS labels been migrated?
> Is there a way to migrate the VSS labels also to some form in SVN?

Is there a "tags" directory? That's where labels are suppose to go.
Normally, conversion utilities have to be told where to put this
directory -- whether it should be at the root of the repository or the
root of the projects directory. The two most common ways are:

/trunk/proj1
/trunk/proj2
/branches/proj1
/branches/proj2
/tags/proj1
tags/proj2

/proj1/trunk
/proj1/tags
/proj1/branches
/proj2/trunk
/proj2/tags
/proj2/branches

Check both locations. Otherwise, you'll have to ask Neil Sleightholm
about his program. I don't know if too many people on this list are
familiar with it.

One of my concerns is that the migrate.pl program doesn't contain the
words "tags" or "branches" in it. I didn't do a code analysis to see
how it works, but unless you passed the names of your tags and
branches directory as parameters, I'd be concerned that tags and
branches weren't being created.

There was something about "Labeled" in the program. It appeared to be
a check in comment, but you can see if that exists as a directory
name, or check your "svn log" for a comment containing the word
"Labeled". If you do, do an svn log and see if you can find the actual
place the tag was created. It should be the revision right after the
"Labeled" comment.

If you can find the comments, but not the tags themselves, you might
be able to write a script to parse your SVN log, find the comments,
and make the tags yourself based upon the revision of those comments.

There are a few other VSS to SVN conversion utilities out there. The
one I'm most familar with are the tools from Polarion
. You might
want to try theirs and see if you get better results. There's also a
vss2svn project at http://www.pumacode.org/projects/vss2svn. Again,
take their utility for a spin and see what the results look like.

Again, your best choice for support on these VSS to SVN projects are
from the sites that offer these projects.

Please let us know what you find, so others who are in the same
situation can benefit from your knowledge. We're all volunteers here.
Most of us are on this list to get help, and some of us can
occasionally offer help in as a way of paying back the help we
previously had.

And, if you do use Subversion, I highly recommend keeping your
subscription on this list. It's a great way to learn about Subversion,
its problems, and the best ways to use it.

Sorry I couldn't be any more help.

-- 
David Weintraub
qazw...@gmail.com

SVN group authentication to AD

[Dale Bohl]

Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this
and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and
authorization

but yet AD Role groups work just fine.

 

subversion.conf config for "puppet" repository



#puppet repo===



   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName "Subversion Authentication to AD"

 

   # Limit R/W access to certain role groups

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   

 

   # Limit R/O access to certain role group

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   



 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown
commented

out, authentication doesn't work and when that happens I'm seeing the
following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in
required group(s).

 

So, even though the following User > Role > Permissions > Resource
association

exists, the group with '-P' in it above won't allow dpb to authenticate
for repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com  
(715)-720-4382

 

Re: Merging case-only renames to branch

[David Weintraub]

On Sun, Nov 14, 2010 at 7:12 PM, Daniel Becroft  wrote:
> Hi,
>
> We've recently had to rename a couple of files on trunk by case only (e.g.
> FOO.C to foo.c), which we did via a URL-only rename. This worked perfectly.
>
> We then encountered a strange error when attempting to merge this revision
> across to our release branch. Because the revision contains both an ADD and
> a DELETE for (essentially) the same file, we got an "Error bumping revisions
> post-commit)" message. I've reproduced the error with a sandpit environment
> using 1.6.13 (below).

Okay, you're using Windows. On Windows, Foo and foo are the same file,
but on Unix, they're two different files. Subversion is suppose to be
case sensitive, so Foo and foo are two different files in Subversion
whether or not the server or client are on Windows systems or Unix
systems.

Do you have any post-commit hooks? If you are, are the messages being
generated by Subversion or the post commit hooks?

-- 
David Weintraub
qazw...@gmail.com

RE: SVN group authentication to AD

[Feldhacker, Chris]

> dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and 
> IT-InfrastructureTeam-SystemAdministrator-R is a member of 
> SVN-Puppet-ReadWrite-P AD group
 

Nested AD groups aren't supported -- not many products do.  Typically, support 
for nested AD groups requires that the client application use the native AD 
APIs rather than generic LDAP APIs.  





From: Dale Bohl [mailto:db...@masoncompaniesinc.com] 
Sent: Monday, November 15, 2010 7:40 AM
To: users@subversion.apache.org
Subject: SVN group authentication to AD



Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and authorization

but yet AD Role groups work just fine.

 

subversion.conf config for "puppet" repository



#puppet repo===



   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName "Subversion Authentication to AD"

 

   # Limit R/W access to certain role groups

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   

 

   # Limit R/O access to certain role group

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   



 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown commented

out, authentication doesn't work and when that happens I'm seeing the following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in 
required group(s).

 

So, even though the following User > Role > Permissions > Resource association

exists, the group with '-P' in it above won't allow dpb to authenticate for 
repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of 
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com  
(715)-720-4382

 



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

RE: SVN group authentication to AD

[Feldhacker, Chris]

Sorry -- disregard my post.  

I overlooked the "Auth_PAMEnabled" line and assumed you were using the standard 
LDAP authz Apache modules, which don't support nested groups.

However, while you're waiting for someone with more PAM knowledge to reply, I 
would wonder if perhaps the cause could be similar -- I would check the 
documentation for the specific PAM module you are using and verify nested 
groups are supported...



-Original Message-
From: Feldhacker, Chris [mailto:feldhacker.ch...@principal.com] 
Sent: Monday, November 15, 2010 7:50 AM
To: Dale Bohl
Cc: users@subversion.apache.org
Subject: RE: SVN group authentication to AD

> dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and 
> IT-InfrastructureTeam-SystemAdministrator-R is a member of 
> SVN-Puppet-ReadWrite-P AD group
 

Nested AD groups aren't supported -- not many products do.  Typically, support 
for nested AD groups requires that the client application use the native AD 
APIs rather than generic LDAP APIs.  





From: Dale Bohl [mailto:db...@masoncompaniesinc.com]
Sent: Monday, November 15, 2010 7:40 AM
To: users@subversion.apache.org
Subject: SVN group authentication to AD



Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and authorization

but yet AD Role groups work just fine.

 

subversion.conf config for "puppet" repository



#puppet repo===



   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName "Subversion Authentication to AD"

 

   # Limit R/W access to certain role groups

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   

 

   # Limit R/O access to certain role group

   

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   



 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown commented

out, authentication doesn't work and when that happens I'm seeing the following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in 
required group(s).

 

So, even though the following User > Role > Permissions > Resource association

exists, the group with '-P' in it above won't allow dpb to authenticate for 
repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of 
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com  
(715)-720-4382

 



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

RE: Subversion vs multicore processors

[Edward Ned Harvey]

> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: Saturday, November 13, 2010 4:38 PM
> 
> On Sat, Nov 13, 2010 at 12:23 AM, Edward Ned Harvey
>  wrote:
> >> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> >>
> >> RHEL 5 still directly only provides Subversion 1.4.2. EPEL will not
> > replace it in
> >
> > On RHEL4 / RHEL5, I find it ridiculously easy to build svn from source.
> > Here is my build script:
> 
> Great: now reliably provide HTTP/HTTPS access for offsite repository use,
> configure mod_dav_svn for local HTTP and HTTPS server usage, utilities
with
> configuration files, and assure that ssn+ssh discovered all the necessary
> libraries. Oh, you didn't have the include files installed for those and
> therefore ./configure didn't detect them?
> Whoops! Guess those parts all got left out of our script! And don't forget
the
> sqlite version issues!!!

Yikes, somebody doesn't mind taking a dump in public!

All I got to say is:  
(a) works for me (including http & https) ... we don't use svn+ssh but I see
no reason it wouldn't work ... I know nothing of any sqlite issues you
allude to (nor do I care), so please put in the level of effort necessary
for things to work for you in your environment, 
and 
(b) other than building from source, there's no better way that I know to
get the latest svn 1.6 in rhel4 / rhel5.  AKA, there are no rpm's available
that I know of, which I trust more than building from source as described.

Re: svnserve : anonymous access not working on SASL

[Daniel Shahaf]

Gingko wrote on Sat, Nov 13, 2010 at 21:18:14 +0100:
> - Original Message - From: "Daniel Shahaf" 
> 
> To: "Gingko" 
> Cc: "Subversion User List" 
> Sent: Wednesday, November 10, 2010 10:45 PM
> Subject: Re: svnserve : anonymous access not working
>
>
>> I agree that anon-access=read should work.  From looking at the code,
>> I'm not sure whether the SASL glue logic signals "I couldn't auth this
>> user", or just returns an error.  In the meantime, as a workaround, does
>> adding ANONYMOUS to the mech_list achieve the desired behaviour?
>
> Hello,
>
> Anything new on this subject ?
> Is there another workaround that you could suggest ?
>

Unfortunately no.  I don't have an SASL setup myself, my advise was
based mostly on reading the code.

> Maybe I should file a bug report about it on your issue tracker  
> (http://subversion.apache.org/issue-tracker.html) ?
>

I hope someone more familiar with SASL could comment.

But if after scanning the usual places (book, archives, SASL docs) you
haven't managed to get SASL + anonymous access to interact properly, I'm
fine with recording an issue for this.  (It might turn out to be
a documentation issue, but that's still a bug.)

Please link to this thread from the issue.

> Gingko 
>

Re: Merging case-only renames to branch

[Daniel Shahaf]

Can you try with a newer 1.7 build?

Re FOO->foo or foo->FOO, I suspect it's because we iterate some hash
table's keys (so the order of iteration is unpredictable).

Daniel
(it's actually a thread for dev@)


Daniel Becroft wrote on Mon, Nov 15, 2010 at 10:12:39 +1000:
> Hi,
> 
> We've recently had to rename a couple of files on trunk by case only (e.g.
> FOO.C to foo.c), which we did via a URL-only rename. This worked perfectly.
> 
> We then encountered a strange error when attempting to merge this revision
> across to our release branch. Because the revision contains both an ADD and
> a DELETE for (essentially) the same file, we got an "Error bumping revisions
> post-commit)" message. I've reproduced the error with a sandpit environment
> using 1.6.13 (below).
> 
> --- Merging r4 through r5 into '.':
> AA\alpha.txt
> DA\ALPHA.TXT
> Sending.
> Deleting   A\ALPHA.TXT
> Adding A\alpha.txt
> svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: In directory 'D:\temp\svn_sandpit\workingcopy\branchA\A'
> svn: Error processing command 'committed' in
> 'D:\temp\svn_sandpit\workingcopy\branchA\A'
> svn: Error getting 'affected time' for
> 'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base'
> svn: Can't stat
> 'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base':
> The system cannot find the file specified.
> 
> Interestingly, if I change my reproduction script to rename from alpha.txt
> to ALPHA.txt, the commit works correctly.
> 
> --- Merging r4 through r5 into '.':
> AA\ALPHA.TXT
> DA\alpha.txt
> Sending.
> Adding A\ALPHA.TXT
> Deleting   A\alpha.txt
> Committed revision 6.
> 
> My question(s) are:
> 1) How should a merge of a case-only rename be managed? Is it a matter of
> merging up to rX, manually renaming in the branch, recording the merge for
> rX, then merging the rest? Or is there a cleaner method?
> 2) Should the order of the rename actually matter? In the above example(s)
> renaming of UPPER to lower caused the error, but renaming from lower to
> UPPER did not.
> 
> The same script (running using an old build of 1.7) gives the following
> message:
> 
> --- Merging r4 through r5 into '.':
> AA\alpha.txt
> DA\ALPHA.TXT
> --- Recording mergeinfo for merge of r4 through r5 into '.':
>  U   .
> Sending.
> Deleting   A\ALPHA.TXT
> Adding A\alpha.txt
> svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: Error processing post-commit work for
> 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt'
> svn: File 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt' has no text
> base
> 
> Different wording, but same problem.
> ---
> Daniel Becroft

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/15/2010 9:17 AM, Edward Ned Harvey wrote:



On RHEL4 / RHEL5, I find it ridiculously easy to build svn from source.
Here is my build script:


Great: now reliably provide HTTP/HTTPS access for offsite repository use,
configure mod_dav_svn for local HTTP and HTTPS server usage, utilities

with

configuration files, and assure that ssn+ssh discovered all the necessary
libraries. Oh, you didn't have the include files installed for those and
therefore ./configure didn't detect them?
Whoops! Guess those parts all got left out of our script! And don't forget

the

sqlite version issues!!!


Yikes, somebody doesn't mind taking a dump in public!

All I got to say is:
(a) works for me (including http&  https) ... we don't use svn+ssh but I see
no reason it wouldn't work ... I know nothing of any sqlite issues you
allude to (nor do I care), so please put in the level of effort necessary
for things to work for you in your environment,
and
(b) other than building from source, there's no better way that I know to
get the latest svn 1.6 in rhel4 / rhel5.  AKA, there are no rpm's available
that I know of, which I trust more than building from source as described.


Has someone had specific problems with the rpmforge rpms? I've been 
using them on centos5 without any trouble, although I don't keep the 
repository enabled during system updates to avoid pulling in other 
packages that might conflict with the base versions.  The only quirk 
I've noticed isn't really with svn or rpmforge, but if you use viewvc 
and have the EPEL repository enabled, yum will pick the epel viewvc 
package and it's configuration is different from the rpmforge version.


For the people who have no idea what this is about: 'yum' is the 
software package manager for the Centos linux distribution, EPEL is a 
third-party package repository that tries not to modify packages 
included in the distribution, and rpmforge is a repository that tries to 
provide newer versions of base packages or versions with more features, 
as well as additional programs.  And yum is fairly easily confused when 
3rd party repositories offer conflicting versions.  My experience has 
been that the rpmforge packages are well maintained, but you have to be 
careful not to let yum pull in more than you need from there.  If you 
don't know how to do that, you can always download the individual rpms 
and install manually.


--
  Les Mikesell
lesmikes...@gmail.com

Re: Problem with diff after merging

[Daniel Shahaf]

Doesn't 'svn diff' say something to the effect of "A file with 
name was added"?


There is also:

% $svn h diff | grep add
  --show-copies-as-adds [--sca] : don't diff copied or moved files with their 
source

... but I think it's only in 1.7.

Jahn Otto Andersen wrote on Mon, Nov 15, 2010 at 10:20:00 +0100:
> I am using a code review tool called ReviewBoard to do code reviews. This
> tool uses svn diff to report the changes between BASE and work area.
> 
>  
> 
> I'm having problems when working in a branch and then merging into trunk.
> This problem seems to be caused by the diff generated by svn diff.
> 
>  
> 
> What I do: 
> 
> 1. Create a new branch based on trunk using TortoiseSVN's "branch" function
> 2. Commit several changes into the branch, including creating new files 
> 3. Reintegrate branch into trunk using TortoiseSVN's "reintegrate branch"
> function.
> 4. Generate the diff using svn diff and use this for the code review 
> 
> The problem is:
> 
> The diff that is created by svn diff does not contain the new file. The diff
> file contains the following lines (given that the new file is named
> NewFile.cs): 
> 
>  
> 
>  
> Property changes on: NewFile.cs 
> ___ 
> Modified: svn:mergeinfo 
>Merged /blabla/branches/mybranch/NewFile.cs:r11226-11336 
> -
> 
>  
> 
> It seems like the diff contains information about the fact that the new file
> is being merged into trunk from the branch, but it doesn't contain the
> actual lines in the new file. As a result, the review request in ReviewBoard
> doesn't contain NewFile.cs at all. 
> 
> Is there any way I can make svn diff include the new lines in the new file?
> 
>  
> 

Re: SVN group authentication to AD

[Daniel Shahaf]

Might be better to ask this on the *...@httpd.apache.org lists?

Dale Bohl wrote on Mon, Nov 15, 2010 at 07:39:59 -0600:
> Hello,
> 
>  
> 
> I've been banging my head on this one for 2 days now.
> 
> I've googled this issue but it appears not many admins are using this
> and/or
> 
> it could possibly be a bug in the apache module.
> 
>  
> 
> Config
> 
> --
> 
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
> 
> Server version: Apache/2.2.3
> 
> svn, version 1.6.12 (r955767)
> 
> Windows 2008 R2
> 
>  
> 
>It appears that we cannot use Active Directory Permissions Groups
> 
> with the s-svn server for Subversion repository authentication and
> authorization
> 
> but yet AD Role groups work just fine.
> 
>  
> 
> subversion.conf config for "puppet" repository
> 
> 
> 
> #puppet repo===
> 
> 
> 
>DAV svn
> 
>SVNPath /repos/puppet
> 
>AuthPAM_Enabled on
> 
>AuthType Basic
> 
>AuthName "Subversion Authentication to AD"
> 
>  
> 
># Limit R/W access to certain role groups
> 
>
> 
> #  Require group SVN-Puppet-ReadWrite-P
> 
>   Require group IT-InfrastructureTeam-SystemAdministrator-R
> 
>
> 
>  
> 
># Limit R/O access to certain role group
> 
>
> 
> #  Require group SVN-Puppet-ReadWrite-P
> 
>   Require group IT-InfrastructureTeam-SystemAdministrator-R
> 
>
> 
> 
> 
>  
> 
> The interesting thing is that AD Role Groups appear to work fine within
> 
> the Location directive config above which shows the role group for which
> 
> I'm a member.
> 
>  
> 
> If the above config is changed to use the Permissions group shown
> commented
> 
> out, authentication doesn't work and when that happens I'm seeing the
> following
> 
> error in ssl_error_log.
> 
>  
> 
> [Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in
> required group(s).
> 
>  
> 
> So, even though the following User > Role > Permissions > Resource
> association
> 
> exists, the group with '-P' in it above won't allow dpb to authenticate
> for repo access.
> 
>  
> 
> dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and
> 
> IT-InfrastructureTeam-SystemAdministrator-R is a member of
> SVN-Puppet-ReadWrite-P AD
> 
> group
> 
>  
> 
> Any help would be greatly appreciated.
> 
>  
> 
> 
> 
> Dale Bohl
> Sr. Systems Administrator
> Mason Companies, Inc.
> db...@masoncompaniesinc.com  
> (715)-720-4382
> 
>  
> 

RE: Subversion vs multicore processors

[Edward Ned Harvey]

> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> 
> On 11/15/2010 9:17 AM, Edward Ned Harvey wrote:
> >
> >>> On RHEL4 / RHEL5, I find it ridiculously easy to build svn from
source.
> >>> Here is my build script:
> 
> Has someone had specific problems with the rpmforge rpms? I've been using
> them on centos5 without any trouble, 

Neither rpmforge, nor epel has subversion >= 1.5 for rhel4.

I used collabnet, when 1.5.0 first came out and building from source was
extremely difficult ... but the collabnet rpm's had lots of "surprises" like
the silent creation of csvn user which conflicts with our company's UID
numbering scheme.  Config files & log files kept in unusual locations.  And
there was some kind of problem with svnsync that I don't remember now, and
stuff like that.  So ... in later versions of 1.5.x, when it became easy to
build from source, I found that building from source was the clear best
solution for the locations where I support it.  Reliable (behaves the same
on all machines).  No surprises.

And the trend continues with 1.6.  Still easy to build, but no rpm's
available that I trust more than what I build from source.

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/15/2010 10:27 AM, Edward Ned Harvey wrote:

From: Les Mikesell [mailto:lesmikes...@gmail.com]

On 11/15/2010 9:17 AM, Edward Ned Harvey wrote:



On RHEL4 / RHEL5, I find it ridiculously easy to build svn from

source.

Here is my build script:


Has someone had specific problems with the rpmforge rpms? I've been using
them on centos5 without any trouble,


Neither rpmforge, nor epel has subversion>= 1.5 for rhel4.


Umm, OK - we're way off topic now but I'd ask the same question about 
running rhel/centos4.x as I would about running subversion 1.4.x...



I used collabnet, when 1.5.0 first came out and building from source was
extremely difficult ... but the collabnet rpm's had lots of "surprises" like
the silent creation of csvn user which conflicts with our company's UID
numbering scheme.  Config files&  log files kept in unusual locations.  And
there was some kind of problem with svnsync that I don't remember now, and
stuff like that.  So ... in later versions of 1.5.x, when it became easy to
build from source, I found that building from source was the clear best
solution for the locations where I support it.  Reliable (behaves the same
on all machines).  No surprises.

And the trend continues with 1.6.  Still easy to build, but no rpm's
available that I trust more than what I build from source.


There's nothing wrong with doing your own compile, but there are good 
reasons to use a distribution's package management tools as much as 
possible.  I'd at least try to take the spec file from a working rpm or 
write your own from scratch if you think you can do it better.  If you 
don't, you are much more likely to set up a scenario where incompatible 
versions co-exist on the same machine in different locations or your 
mod_dav_svn don't match the installed httpd.


--
  Les Mikesell
   lesmikes...@gmail.com

Migration from QVCS to Subversion

[Flavien]

Hi,



I'm looking for a way to convert our QVCS repository to Subversion
while keeping the history, commit messages and all.

The only thread I found on the subject dates back to 2004, and has
seen no answer :
http://svn.haxx.se/users/archive-2004-10/1104.shtml

Hopefully the situation has evolved now and some of you have ideas
on the subject. (note that I would also consider service offers as
this operation is a one shot one).


Thanks for your help,

Flavien.

Re: Migration from QVCS to Subversion

[David Weintraub]

On Mon, Nov 15, 2010 at 12:19 PM, Flavien  wrote:
> Hi,
>
> I'm looking for a way to convert our QVCS repository to Subversion
> while keeping the history, commit messages and all.
>
> The only thread I found on the subject dates back to 2004, and has
> seen no answer :
> http://svn.haxx.se/users/archive-2004-10/1104.shtml
>
> Hopefully the situation has evolved now and some of you have ideas
> on the subject. (note that I would also consider service offers as
> this operation is a one shot one).

QVCS is a very proprietary tool, and I have never seen it in action
after almost three decades of CM work. I checked with a few resources
that do Subversion migrations, and most have never heard of the tool,
and no one knew of a conversion utility. It looks like you'll have to
hire someone to write one for you.

And that's even if it is possible. In order to pull out the data from
an old version control system, you either need a public API or use the
various command line tools. Although QVCS has a command line toolset,
it's very sparse. Their webpage lists only a bit more than a dozen
commands, and unless you have the pro version, you can't do any of
these commands recursively.

It might be time to do a bit of triage. Getting all of your history
and commit messages is nice, but is it necessary? If you keep your old
QVCS system up and running, you'll still have access to your history
from that. A possibility is to do a limited conversion of just the
active branches and tags. Maybe even take the time for a bit of
repository restructuring -- move projects into more logical
arangements and get rid of the obsolete cruft.

Unfortunately, things have probably gotten worse since 1994. Back
then, many people refused to trust open source tools. Subversion was a
fairly new project. There were a lot of companies offering proprietary
version control tools. Now, even major banks are jumping on the open
source bandwagon and its gettng harder and harder to find people who
know these tools.

-- 
David Weintraub
qazw...@gmail.com

Re: Merging case-only renames to branch

[Daniel Becroft]

 On Mon, Nov 15, 2010 at 11:44 PM, David Weintraub wrote:

> On Sun, Nov 14, 2010 at 7:12 PM, Daniel Becroft 
> wrote:
> > Hi,
> >
> > We've recently had to rename a couple of files on trunk by case only
> (e.g.
> > FOO.C to foo.c), which we did via a URL-only rename. This worked
> perfectly.
> >
> > We then encountered a strange error when attempting to merge this
> revision
> > across to our release branch. Because the revision contains both an ADD
> and
> > a DELETE for (essentially) the same file, we got an "Error bumping
> revisions
> > post-commit)" message. I've reproduced the error with a sandpit
> environment
> > using 1.6.13 (below).
>
> Okay, you're using Windows. On Windows, Foo and foo are the same file,
> but on Unix, they're two different files. Subversion is suppose to be
> case sensitive, so Foo and foo are two different files in Subversion
> whether or not the server or client are on Windows systems or Unix
> systems.
>

I realize that, hence why we did our initial renames via URLs, rather than
in a working copy. My question was not so much "Why did I get this
message?", but how should such a change be merged between trunk and branch.
Any merge requires a working copy.

I suspect that the correct method is:
 - Merge everything up to and including) rX-1, and commit.
 - Rename file manually over URL
 - Record-only merge of rX
 - Merge everything from (and including) rX+1 to HEAD, and commit.


> Do you have any post-commit hooks? If you are, are the messages being
> generated by Subversion or the post commit hooks?
>

The messages are being generated by the client (there were no post-commit
hooks in my sample repository).

Cheers,
Daniel B.

Re: Merging case-only renames to branch

[Erik Huelsmann]

On Mon, Nov 15, 2010 at 10:07 PM, Daniel Becroft  wrote:
> On Mon, Nov 15, 2010 at 11:44 PM, David Weintraub  wrote:
>>
>> On Sun, Nov 14, 2010 at 7:12 PM, Daniel Becroft 
>> wrote:
>> > Hi,
>> >
>> > We've recently had to rename a couple of files on trunk by case only
>> > (e.g.
>> > FOO.C to foo.c), which we did via a URL-only rename. This worked
>> > perfectly.
>> >
>> > We then encountered a strange error when attempting to merge this
>> > revision
>> > across to our release branch. Because the revision contains both an ADD
>> > and
>> > a DELETE for (essentially) the same file, we got an "Error bumping
>> > revisions
>> > post-commit)" message. I've reproduced the error with a sandpit
>> > environment
>> > using 1.6.13 (below).
>>
>> Okay, you're using Windows. On Windows, Foo and foo are the same file,
>> but on Unix, they're two different files. Subversion is suppose to be
>> case sensitive, so Foo and foo are two different files in Subversion
>> whether or not the server or client are on Windows systems or Unix
>> systems.
>
> I realize that, hence why we did our initial renames via URLs, rather than
> in a working copy. My question was not so much "Why did I get this
> message?", but how should such a change be merged between trunk and branch.
> Any merge requires a working copy.
>
> I suspect that the correct method is:
>  - Merge everything up to and including) rX-1, and commit.
>  - Rename file manually over URL
>  - Record-only merge of rX
>  - Merge everything from (and including) rX+1 to HEAD, and commit.

All that I can add to this discussion is that with 1.7 (wc-ng) this
will actually start to work! (as in: it works on trunk/ today! yay!
finally!)

>> Do you have any post-commit hooks? If you are, are the messages being
>> generated by Subversion or the post commit hooks?
>
> The messages are being generated by the client (there were no post-commit
> hooks in my sample repository).
>
> Cheers,
> Daniel B.
>

Bye,


Erik.

reverting to a older revision in svn

[Tom Cruickshank]

Hey Guys,
 I'm trying to figure out how to revert a file committed into svn to an
older revision.

Let's say I have a file called /customers/index.php currently at revision
150, and would like to go back to revision 100.

it's the only file I would like to revert. What arguments might I need to
accomplish this?

I'm surfing the web and having problems

got this so far:

svn merge -r 150:110 /customers/index.php

this is typed in my checkout. Is that the correct place for it?

Thanks for any assistance.

Tom

Re: reverting to a older revision in svn

[Andy Levy]

On Mon, Nov 15, 2010 at 16:55, Tom Cruickshank  wrote:
> Hey Guys,
>      I'm trying to figure out how to revert a file committed into svn to an
> older revision.
> Let's say I have a file called /customers/index.php currently at revision
> 150, and would like to go back to revision 100.
> it's the only file I would like to revert. What arguments might I need to
> accomplish this?
> I'm surfing the web and having problems
> got this so far:
> svn merge -r 150:110 /customers/index.php
> this is typed in my checkout. Is that the correct place for it?

Yes. 
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

Getting mod_dav_svn binary

[Ravi Rajamiyer]

Hello,

I am setting up a new SVN repo for my project with Apache server. I would like 
to get a precompiled version of the 'mod_dav_svn.so' file for subversion 
version 1.6.13 and for Fedora Linux core 14. Is there a resource where I can 
download the '.so' file from?

Thanks

Ravi

Re: Subversion vs multicore processors

[Nico Kadel-Garcia]

On Mon, Nov 15, 2010 at 11:27 AM, Edward Ned Harvey  wrote:
>> From: Les Mikesell [mailto:lesmikes...@gmail.com]
>>
>> On 11/15/2010 9:17 AM, Edward Ned Harvey wrote:
>> >
>> >>> On RHEL4 / RHEL5, I find it ridiculously easy to build svn from
> source.
>> >>> Here is my build script:
>>
>> Has someone had specific problems with the rpmforge rpms? I've been using
>> them on centos5 without any trouble,
>
> Neither rpmforge, nor epel has subversion >= 1.5 for rhel4.

I helped write the RPM's for RPMforge use (not primary author, merely
a contributor).

I tried working with Subverserion 1.6.x for RHEL 4, and the
dependencies get out of hand, including Python dependencies for the
build utilities, and fascinating issues with the 'svn help' command
for x86_64 architectures.

For RHEL 5, they're great. The one issue is that RPMforge does not
publish .i386 versions of packages in the x86_64 repository, and
RedHat does, so you can wind up with conflicts with the out of date
and entirely unnecessary i386 versions of components if you just use
"yum install subversion".

I simply flush the '.i386' versions of these components as entirely
unnecessary on an x86_64 host.

> stuff like that.  So ... in later versions of 1.5.x, when it became easy to
> build from source, I found that building from source was the clear best
> solution for the locations where I support it.  Reliable (behaves the same
> on all machines).  No surprises.
>
> And the trend continues with 1.6.  Still easy to build, but no rpm's
> available that I trust more than what I build from source.

Take a look at the SRPM's, if you want a higher level of confidence.
The .spec files are legible and the patches intelligible,  to get it
to work with RedHat's structures and avoid dependency problems with
other tools that use Subversion. (

Re: Subversion vs multicore processors

[Nico Kadel-Garcia]

On Mon, Nov 15, 2010 at 10:17 AM, Edward Ned Harvey  wrote:

> (b) other than building from source, there's no better way that I know to
> get the latest svn 1.6 in rhel4 / rhel5.  AKA, there are no rpm's available
> that I know of, which I trust more than building from source as described.

For RPM users, http://rpm.pbone.net/ is fabulous for finding these
sorts of updates. That points straight to RPMforge for the relevant
RHEL 5 or CentOS 5 updates for Subversion.

Re: Getting mod_dav_svn binary

[Andy Levy]

On Mon, Nov 15, 2010 at 17:08, Ravi Rajamiyer  wrote:
>
> Hello,
>
> I am setting up a new SVN repo for my project with Apache server. I would 
> like to get a precompiled version of the 'mod_dav_svn.so' file for subversion 
> version 1.6.13 and for Fedora Linux core 14. Is there a resource where I can 
> download the '.so' file from?

The same place you got the rest of your Subversion installation;
either compile with the appropriate options, or install the other
RPMs.

RE: reverting to a older revision in svn

[Edward Ned Harvey]

> From: Tom Cruickshank [mailto:tcruic...@gmail.com]
> 
> Hey Guys,
>      I'm trying to figure out how to revert a file committed into svn to
an older
> revision.
> 
> Let's say I have a file called /customers/index.php currently at revision
150,
> and would like to go back to revision 100.
> 
> it's the only file I would like to revert. What arguments might I need to
> accomplish this?

svn rm ./foo
svn cp -r 100 foo ./foo

What you've done is delete the file which was created by all the changes
from 100 to 150.  Then you've restored rev 100, and commit rev 151.  Now, if
you "svn log foo" you'll see the history of the file up to rev 100, and then
a jump directly to 151, skipping all the changes from 101 to 150.  You've
basically chopped off the branch that led to a bad file, and re-grafted a
good branch in its place.

If you want to see the bad version again, you could always checkout rev 150.
All the info still exists in repo.  But you've deleted that file, and
replaced it with another file having the same name, and part of the same
history.

RE: Subversion vs multicore processors

[Edward Ned Harvey]

> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> 
> > On RHEL4 / RHEL5, I find it ridiculously easy to build svn from
> > source.
> > Here is my build script:
> >>
> >> Has someone had specific problems with the rpmforge rpms? I've been
> >> using them on centos5 without any trouble,
> >
> > Neither rpmforge, nor epel has subversion>= 1.5 for rhel4.
> 
> Umm, OK - we're way off topic now but I'd ask the same question about
> running rhel/centos4.x as I would about running subversion 1.4.x...

This has already been mentioned in this thread.  I can't speak for anyone
else, but I personally support engineers and engineering tools.  The
engineering tools are only supported on the latest 2 versions of
RHEL/centos.  Of which, the latest one is perpetually unstable.  So I run
RHEL4 as long as RHEL5 is the current release...  But a few days ago RHEL6
was released, so now it's time to upgrade to RHEL5 and ditch RHEL4.


> There's nothing wrong with doing your own compile, but there are good
> reasons to use a distribution's package management tools as much as
> possible.  

I fully agree.  For the sake of simplicity in upgrades, knowing (or blindly
trusting) it was compiled by an expert, dependency checking, etc.  Ability
to remove package if you want to.  If there is an rpm out there that suits
your needs (except the collabnet one) I would normally recommend using it.
I fundamentally object to the collabnet one, because it has scripted
"useradd" as part of the rpm post-run scripts.  This process is not
consistent or repeatable on different machines, nor is it necessary on my
machines.  So after I was bitten by UID conflict, I had to script userdel as
a command to follow the rpm installation.

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/15/10 8:23 PM, Edward Ned Harvey wrote:





Has someone had specific problems with the rpmforge rpms? I've been
using them on centos5 without any trouble,


Neither rpmforge, nor epel has subversion>= 1.5 for rhel4.


Umm, OK - we're way off topic now but I'd ask the same question about
running rhel/centos4.x as I would about running subversion 1.4.x...


This has already been mentioned in this thread.  I can't speak for anyone
else, but I personally support engineers and engineering tools.  The
engineering tools are only supported on the latest 2 versions of
RHEL/centos.  Of which, the latest one is perpetually unstable.


I guess that's a matter of  opinion, but seriously, Red Hat Enterprise, 
unstable??? I don't think so.  Maybe you've confused it with fedora.  I do 
recall a few problems with 4.x early on though - and I replaced them all with 
5.x as quickly as possible.


--
  Les Mikesell
lesmikes...@gmail.com

URL-only renames adds svn:mergeinfo property

[Daniel Becroft]

Hi,

I've just found (another) issue with using URL-only renames. If one of the
parent directories has svn:mergeinfo recorded on it, then renaming a file
via a URL results in the new file containing a full copy of what was on the
trunk (but cut down to the individual file).

Please see the following output from my test script (using SVN 1.6.13):

>svn merge file:///D:/temp/svn_sandpit/repository/trunk .
--- Merging r4 through r5 into '.':
UA\alpha.txt

>svn commit . --message "Merge r5 from trunk to branch."
Sending.
SendingA\alpha.txt
Transmitting file data .
Committed revision 6.

>svn propget svn:mergeinfo
file:///D:/temp/svn_sandpit/repository/branches/branchA
/trunk:4-5

>svn propget svn:mergeinfo
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt

>svn rename
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt --message
"Rename alpha.txt to beta.txt on branchA."
Committed revision 7.

>svn propget svn:mergeinfo
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt
/trunk/A/alpha.txt:4-5

Notice that the 'svn propget' on alpha.txt indicates that there is no
svn:mergeinfo property available, but it gets added to beta.txt during the
rename.

Is this intended behavior?


Daniel Becroft

RE: SVN Migration from VSS

[Cooke, Mark]

 

> -Original Message-
> From: David Weintraub [mailto:qazw...@gmail.com] 
> Sent: 15 November 2010 13:36
> To: Neson Maxmelbin (RBEI/EMT5)
> Cc: users@subversion.apache.org
> Subject: Re: SVN Migration from VSS
> 
> On Mon, Nov 15, 2010 at 7:28 AM, Neson Maxmelbin (RBEI/EMT5)
>  wrote:
> >
> > I did a migrate of a project from VSS to SVN using the 
> migrate.pl from
> > 
> http://neilsleightholm.blogspot.com/2007/08/migrating-from-vis
ual-source-safe-to.html
> > .
> >
> > Migration was ok . But I cant see the VSS labels been migrated?
> > Is there a way to migrate the VSS labels also to some form in SVN?
> 

> 
> There are a few other VSS to SVN conversion utilities out there. The
> one I'm most familar with are the tools from Polarion
> . You might
> want to try theirs and see if you get better results. There's also a
> vss2svn project at http://www.pumacode.org/projects/vss2svn. Again,
> take their utility for a spin and see what the results look like.
> 
Vss2svn has moved to http://code.google.com/p/vss2svn/ but is no longer
in active development.  There is a mailing list and there have been a
few questions/answers over the last few months but it is not exactly
high traffic.  However, we used this to convert some repositories with
success, the labels are imported into a /labels/ folder.  If your
archive contains multiple projects then you may need to do a bit of work
filtering the labels into separate tags folders but that's up to you.
In the end we mostly extracted (dump filtered) the projects that were
still active into new svn repositories and left the whole converted
archive repo as read-only access for reference.

> Again, your best choice for support on these VSS to SVN projects are
> from the sites that offer these projects.
> 
> Please let us know what you find, so others who are in the same
> situation can benefit from your knowledge. We're all volunteers here.
> Most of us are on this list to get help, and some of us can
> occasionally offer help in as a way of paying back the help we
> previously had.
> 
> And, if you do use Subversion, I highly recommend keeping your
> subscription on this list. It's a great way to learn about Subversion,
> its problems, and the best ways to use it.
> 
I second that, I learn a lot from this list...

~ mark c

> Sorry I couldn't be any more help.
> 
> -- 
> David Weintraub
> qazw...@gmail.com
>