RE: SVN Migration from VSS

[Neson Maxmelbin (RBEI/EMT5)]

-Original Message-
From: Cooke, Mark [mailto:mark.co...@siemens.com]
Sent: Tuesday, 16. November 2010 12:36 PM
To: David Weintraub; Neson Maxmelbin (RBEI/EMT5)
Cc: users@subversion.apache.org
Subject: RE: SVN Migration from VSS



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


I used SVNImporter , but again it does only additions to the trunk folder , the 
other folders (tags and branches) are not created at all.
In the log files, there is no mention of the VSS labels, so I am not sure if 
anything failed.
However, in the properties of the SVN revisions, I find the labels listed as an 
attribute value to property name "VSSRevisionLabel".
Is there something I am doing wrong, which si causing the tags not being 
created?

In the config.properties the settings as follows -

srcprovider=vss
import_dump_into_svn=yes

#existing_svnrepos=yes

clear_svn_parent_dir=yes

use_only_last_revision_content=no
file_description_property_key=description

use_file_copy=yes


trunk_path=trunk
branches_path=branches
tags_path=tags
svnimporter_user_name=SvnImporter
only_trunk=no

svnadmin.executable=svnadmin.exe
svnadmin.repository_path=c:/SVN/Checkbit6
svnadmin.parent_dir=.
svnadmin.tempdir=c:/temp/local
svnclient.executable=svn.exe
svnadmin.verbose_exec=yes
#svnadmin.import_timeout=180

svnadmin.path_not_exist_signature=non-existent in that revision
#svnadmin.path_not_exist_signature=existiert nicht in dieser Revision



vss.class=org.polarion.svnimporter.vssprovider.VssProvider
vss.executable=C:\\Program Files\\Microsoft Visual Studio\\VSS\\win32\\ss.exe
vss.path=kor\\MEx_DB
vss.project=$/Checkbit
vss.username=max*
vss.password=""
vss.tempdir=c:/temp/local
vss.log.dateformat=MM.dd.yy hh:mma
vss.log.datelocale=en
vss.log.encoding=Cp1251
# if enabled - dump output of vss.executable command to stdout
vss.verbose_exec=yes
#if enabled, com-api is used instead of ss.exe
vss.use.com.api=yes

SVN Process

[Neson Maxmelbin (RBEI/EMT5)]

Hello .

I want to setup a reliable development process for SVN in our environment.

Here is what I am planning to propose for the process.

Each project in the repository will have the following folders -
-branches
-tags
-trunk

The initial baseline of the project will be in trunk folder.

For the first Release, the trunk is checked out , changes made and then 
commited into trunk.
It should then be tagged into the tags folder as Release_xyx .
The tag Release_xyz is then considered as baseline for the next Release.

For the next Release, developers should checkout from the tag Release_xyz .
Make the necessary code changes.
Switch to trunk
Commit changes to trunk
After all changes are done, Integrator tags the HEAD revision to a new tag 
Release_xyz2

-

My questions -
*   Does this sound like a common procedure followed by SVN users and is it 
reliable?
*   Do you foresee any issues with this process
*   How can I prevent people from commiting into tags
*   Can I lock a tag?
*   While tagging I get options for "Create copy in Repository from"  1> 
Head revision from Repository , 2> Specific revision from repository 3> Working 
copy . I always choose the first option. Is it correct?
*   With regards to the tags, does the SVN repository maintain a full copy 
or only a delta copy ?

I appreciate your valuable suggestions. Thanks


Thanks and Regards
Maxmelbin Neson

svn:externals format

[Christoph Bartoschek]

Hi,

what is the advantage of using

^/trunk/project/subproj...@40  subproject

compared to 

-r 40  ^/trunk/project/subproject  subproject

?

Is it the case that the first version works if ^/trunk/project/subproject is 
deleted in a later revision and the second version fails?

Christoph

RE: Subversion vs multicore processors

[Edward Ned Harvey]

> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> 
> > 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.

Have we had enough discussion of RHEL4 yet?  The whole point of the
discussion was:  There is no svn 1.5 or 1.6 available for RHEL4, from any of
the "standard" repositories.  I choose to build from source, and posted how
I do it, to show that it's easy.  

Do we really need to continually rehash the discussion of why anyone would
ever use RHEL4???

This is definitely off topic, but it's not RHEL4 or RHEL5 that's unstable.
It's the engineering tools, if you run them on whichever is the latest
version of RHEL.  Because the developers who produce the tools don't have
access to the latest OS until the same time when you do.  That means when
it's released, they start debugging things at the rate customers complain
about them.  And since most of the customers are like me - conservative and
resistant to changing the engineering development environment - it means the
debug time for the application on the new OS is a long time.

For these engineering tools, I choose to run the fully patched oldest
supported OS, and only upgrade when support is ending for it.  Hence, I am
currently upgrading from RHEL4 to RHEL5, because RHEL6 was just released.
Can we let this topic die now?

Re: svn:externals format

[Stefan Sperling]

On Tue, Nov 16, 2010 at 01:43:35PM +0100, Christoph Bartoschek wrote:
> Hi,
> 
> what is the advantage of using
> 
> ^/trunk/project/subproj...@40  subproject

This new format does support relative URLs.
 
> compared to 
> 
> -r 40  ^/trunk/project/subproject  subproject

This old format doesn't support relative URLs.
You can only use full URLs (http://svn.example.com/...) with this format.

See "svn help propset" for more information.

Stefan

RE: svn:externals format

[Ludwig, Michael]

> > what is the advantage of using
> > 
> > ^/trunk/project/subproj...@40  subproject
> 
> This new format does support relative URLs.

Are there many files beginning with a caret?

If not, it would also be convenient for:

* svn list
* svn cat
* svn copy
* svn move
* svn diff
* ...

Basically everything working with URLs.

Michael

Re: svn:externals format

[Stefan Sperling]

On Tue, Nov 16, 2010 at 02:55:17PM +0100, Christoph Bartoschek wrote:
> Am Dienstag, 16. November 2010 schrieb Stefan Sperling:
> > On Tue, Nov 16, 2010 at 01:43:35PM +0100, Christoph Bartoschek wrote:
> > > Hi,
> > > 
> > > what is the advantage of using
> > > 
> > > ^/trunk/project/subproj...@40  subproject
> > 
> > This new format does support relative URLs.
> > 
> > > compared to
> > > 
> > > -r 40  ^/trunk/project/subproject  subproject
> > 
> > This old format doesn't support relative URLs.
> > You can only use full URLs (http://svn.example.com/...) with this format.
> > 
> > See "svn help propset" for more information.
> 
> svn help propset states that relative URLs also work for the old format.

Sorry, I got mixed up about the old and new formats.

The new format is as follows: '[-rN]   u...@m]   PATH'
The old format was: 'PATH   [-rN]   URL'

The real difference between the old and new formats is that the URL cannot
have a peg revision in the old format (support for peg revisions in
svn:externals was added in r863820). This means that, using the old format,
one cannot refer to URLs which have been deleted in the HEAD revision.

> We currently use the old format with relative URLs:
> 
> 
>  "Relative URLs are supported in Subversion 1.5 and greater for
>   all above formats and are indicated by starting the URL with one
>   of the following strings"

I've tried this using the actual old format (PATH [-rN] URL),
and you're correct. Relative URLs are supported in either format.

Thanks,
Stefan

Re: SVN Process

[Les Mikesell]

On 11/16/2010 3:52 AM, Neson Maxmelbin (RBEI/EMT5) wrote:

Hello .
I want to setup a reliable development process for SVN in our environment.
Here is what I am planning to propose for the process.

Each project in the repository will have the following folders -
-branches
-tags
-trunk
The initial baseline of the project will be in /trunk/ folder.
For the first Release, the trunk is checked out , changes made and then
commited into trunk.
It should then be tagged into the /tags /folder as Release_/xyx ./
The tag Release_/xyz /is then considered as baseline for the next Release.
For the next Release, developers should checkout from the tag
Release_/xyz /.
Make the necessary code changes.
Switch to /trunk/
Commit changes to trunk
After all changes are done, Integrator tags the HEAD revision to a new
tag Release_/xyz2/
-
My questions -

* Does this sound like a common procedure followed by SVN users and
  is it reliable?


Not quite, but I think another response has addressed how to merge 
things and that you normally don't check tags out for further 
development.  Also, note that a 'switch' does an implicit update of your 
workspace to the new target so it won't work quite like you seem to expect.



* Do you foresee any issues with this process


There are two common styles of development and you should consider which 
you want to follow before starting.  One is to do nearly all development 
on the trunk, branching for new work only when planning disruptive or 
experimental changes that you want to isolate from others.  Then as you 
approach what may be release points you copy to a branch for final 
testing and revisions that may be specific to this release - and you may 
copy to tags for testing and potential release versions.  Any 
maintenance work on this release would continue on this release branch. 
 This lets you support multiple concurrent released versions while 
everyone has easy access to each others' new work on the trunk.


The other style is to always have a clean copy of the latest release on 
the trunk while development happens on one or more branches.  This might 
be more appropriate for a public-facing site where people always expect 
to be able to check out the trunk and get a tested/working version.



* How can I prevent people from commiting into tags
* Can I lock a tag?


This is mostly convention.  As far as svn is concerned directories are 
all the same, although you can use hook scripts to control modifications 
if you want.  Normally you just wouldn't check out a tag for 
modification.  If you didn't follow a work flow that always creates a 
branch copy for work before copying on to the tag, you can copy a tag to 
create the branch if you need to use it as a starting point.



* While tagging I get options for "Create copy in Repository from"
  1> Head revision from Repository , 2> Specific revision from
  repository 3> Working copy . I always choose the first option. Is
  it correct?


Maybe...  It would be safer to commit your changes, then use the 
resulting revision as the copy source.  If you take HEAD, you might get 
a revision someone else just committed with changes you don't know about 
and if you use the working copy you can accidentally pick up files that 
haven't been committed elsewhere.



* With regards to the tags, does the SVN repository maintain a full
  copy or only a delta copy ?


From the client's perspective it always looks like a full copy no 
matter what you check out, but differences between revisions in the 
repository may be deltas and things that are copied are just different 
names for the same items.


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

Re: svn:externals format

[Stefan Sperling]

On Tue, Nov 16, 2010 at 05:11:49PM +0100, Stefan Sperling wrote:
> The new format is as follows: '[-rN]   u...@m]   PATH'
> The old format was: 'PATH   [-rN]   URL'
> 
> The real difference between the old and new formats is that the URL cannot
> have a peg revision in the old format (support for peg revisions in
> svn:externals was added in r863820). This means that, using the old format,
> one cannot refer to URLs which have been deleted in the HEAD revision.

Correction: Because in the old format, the peg revision defaults to the
operative (-r) revision, it's possible to refer to a URL that was
deleted in HEAD. But if a path was deleted and recreated multiple times,
only the most recent instance of it will be usable from svn:externals.
The new format can refer to any instance.

Stefan

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/16/2010 7:03 AM, Edward Ned Harvey wrote:


Do we really need to continually rehash the discussion of why anyone would
ever use RHEL4???


No, but we needed to hash it enough to establish that your 'unstable' 
comment about RHEL5 had to do with quirks of your environment or 
choices, not that RHEL5 is an unsuitable platform for running subversion.



This is definitely off topic, but it's not RHEL4 or RHEL5 that's unstable.
It's the engineering tools, if you run them on whichever is the latest
version of RHEL.  Because the developers who produce the tools don't have
access to the latest OS until the same time when you do.


That's not true in general.  Fedora releases cycle much faster than RHEL 
and almost everything that appears in RHEL has been available in fedora 
for a while, getting the bugs shaken out.  And RHEL itself has beta 
releases with ample time for remaining bugs to be found and fixed.



That means when
it's released, they start debugging things at the rate customers complain
about them.


But, in many, perhaps most, cases, the application developers fix the 
bugs only in new releases where they are also adding new features.  How 
much support would you expect subversion developers to throw at a bug 
you might find in a 1.4.x release, for example?   And RHEL by policy 
rarely includes 'new feature' changes until their next major release.



For these engineering tools, I choose to run the fully patched oldest
supported OS, and only upgrade when support is ending for it.  Hence, I am
currently upgrading from RHEL4 to RHEL5, because RHEL6 was just released.
Can we let this topic die now?


Yes, as long as it is clear that nothing is wrong with RHEL5 (or you 
have a specific problem you've experienced that might affect others). 
But I still can't quite reconcile this concept with compiling some 
things straight from developers' source.


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

RE: Subversion vs multicore processors

[David Aldrich]

Hi

With some trepidation ;-) I would like to ask for opinions, somewhat related to 
this thread.

My understanding is that RHEL is intended for servers that must be rock solid 
e.g. Web servers.  In our organisation we run Centos 5 (essentially the same as 
RHEL 5) on all our Linux development machines. This means that the 'engineering 
tools' such as gcc, cmake, boost etc. can become quite dated.

Would people generally recommend a 'less stable' distro for development 
machines?

Best regards 

David 

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/16/2010 11:23 AM, David Aldrich wrote:

Hi

With some trepidation ;-) I would like to ask for opinions, somewhat related to 
this thread.

My understanding is that RHEL is intended for servers that must be rock solid 
e.g. Web servers.  In our organisation we run Centos 5 (essentially the same as 
RHEL 5) on all our Linux development machines. This means that the 'engineering 
tools' such as gcc, cmake, boost etc. can become quite dated.

Would people generally recommend a 'less stable' distro for development 
machines?


I doubt if there is a generic answer to that question, but with RHEL6 
recently released, maybe Centos6 will be released soon enough for your 
next upgrade and won't be outdated for a while.  If you want the 
tradeoffs of faster update cycles, the main players are fedora and 
ubuntu where fedora uses the same rpm packaging and administration tools 
as rhel/centos and ubuntu is more like Debian but focused on ease of 
installation and use.  In some cases you can take newer application 
versions from fedora as source rpms and rebuild them on an older centos 
- or find them prebuilt at 3rd party RPM repositories like rpmforge.


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

Re: Getting mod_dav_svn binary

[Ravi Rajamiyer]

 I was able to use yum install to get the module on Fedora 14

yum install mod_dav_svn.so

Thanks  for all the input.

Ravi

--- On Mon, 11/15/10, Andy Levy  wrote:

From: Andy Levy 
Subject: Re: Getting mod_dav_svn binary
To: "Ravi Rajamiyer" 
Cc: users@subversion.apache.org
Date: Monday, November 15, 2010, 5:34 PM

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: Subversion vs multicore processors

[Edward Ned Harvey]

> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> 
> > This is definitely off topic, but it's not RHEL4 or RHEL5 that's
unstable.
> > It's the engineering tools, if you run them on whichever is the latest
> > version of RHEL.  Because the developers who produce the tools don't
> have
> > access to the latest OS until the same time when you do.
> 
> That's not true in general.  Fedora releases cycle much faster than RHEL

You seem to be taking my specific comments, about my specific environment,
and misinterpreting them as some sort of generalization.  That is not, and
never was the point that I made.  I am not making a generalization about
RHEL or engineering tools in general.  I have specific set of tools to
support, which are only supported on the latest 2 versions of RHEL.  Of
which, things will be more difficult to support on the latest RHEL.

No generalization.  There is a specific reason why I use RHEL4, and now that
RHEL6 is out, it's time to upgrade to RHEL5.  I feel like a broken record
repeating myself here.

I don't know what the reasons are for other people to still use RHEL4.  No
generalization.  I'm just stating my own reasons.

And I'm only stating my own reasons, because of your obnoxious comments that
judgementally hinted there's no good reason to use an old OS.

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/16/10 8:29 PM, Edward Ned Harvey wrote:



This is definitely off topic, but it's not RHEL4 or RHEL5 that's

unstable.

It's the engineering tools, if you run them on whichever is the latest
version of RHEL.  Because the developers who produce the tools don't

have

access to the latest OS until the same time when you do.


That's not true in general.  Fedora releases cycle much faster than RHEL


You seem to be taking my specific comments, about my specific environment,
and misinterpreting them as some sort of generalization.


Yes, I did take the subject of your 2nd sentence here to mean RHEL/centos, not 
your own programs:


   "The engineering tools are only supported on the latest
2 versions of RHEL/centos.  Of which, the latest one
is perpetually unstable."


And I'm only stating my own reasons, because of your obnoxious comments that
judgementally hinted there's no good reason to use an old OS.


And my reply wasn't intended to be judgmental about your use, but to point out 
to others that in my experience Centos5 is a perfectly stable platform for 
subversion - to counter what I misread as your claim to the contrary.  Sorry 
about that - and good luck when you do update.


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