Source Control - Again

I'm starting to develop a keen distaste for subversion.  It seems when it 
works, it works well, but it sure has its perculiarities.  We have used it 
with both TortoiseSVN and SmartSVN.

For small projects it seems ok.  A recent large project was truly painful. 
This involved about 100 MS Word docs, a bunch of source files and an Eclipse 
project.  Since the Eclipse project had about 35 subprojects, the .metadata 
folder was quite large.  Most items had been committed as they were done 
and/or changing.  With the eclipse projects there was a lot of variations on 
a common project.  Many of these were created on eclipse by a copy project 
sequence and then renamed.  This caused a surprising side effect.  Each time 
a project was copied, all of the hidden .svn folders were also copied.  I 
though SVN was developed in an eclipse environment,  surely it should be 
aware of this.

Attempting to add the new projects to the SVN database gave repeated errors. 
Clean up failed to find or fix the problems. It just failed.  Ultimately the 
solution seemed to be to get rid of the copied .svn folders, then perform 
the clean up, then proceed as originally intended.  Painful and tedious and 
fraught with error.

The main project .metedata folder took 30 minutes to add to SVN.  Then the 
commit failed with a message that the folder already existed in the SVN 
tree.

With the .svn folders created by the add process, the .metadata grew to 59 
Mbytes!

Now that I've whined about that, has anyone experience with Visual 
SourceSafe in a version newer than the 6.0?

I admit some of our problem may be that we have been very familiar with VSS 
for a long time.  We have multiple gigabytes of projects in VSS files and 
never had the level of difficulty that SVN has caused.  Version 5 sucked. 
Version 6 has worked fine for a long time.  So, how does the 2003 or later 
version work?  Oh, I should qualify that I'm not interested in big expensive 
enterprise version.

Scott
Validated Software 

"Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> writes:

> I'm starting to develop a keen distaste for subversion.  It seems when it 
> works, it works well, but it sure has its perculiarities.  We have used it 
> with both TortoiseSVN and SmartSVN.
>
> For small projects it seems ok.  A recent large project was truly painful. 
> This involved about 100 MS Word docs, a bunch of source files and an Eclipse 
> project.  Since the Eclipse project had about 35 subprojects, the .metadata 
> folder was quite large.  Most items had been committed as they were done 
> and/or changing.  With the eclipse projects there was a lot of variations on 
> a common project.  Many of these were created on eclipse by a copy project 
> sequence and then renamed.  This caused a surprising side effect.  Each time 
> a project was copied, all of the hidden .svn folders were also copied.  I 
> though SVN was developed in an eclipse environment,  surely it should be 
> aware of this.
>
> Attempting to add the new projects to the SVN database gave repeated errors. 
> Clean up failed to find or fix the problems. It just failed.  Ultimately the 
> solution seemed to be to get rid of the copied .svn folders, then perform 
> the clean up, then proceed as originally intended.  Painful and tedious and 
> fraught with error.
>
> The main project .metedata folder took 30 minutes to add to SVN.  Then the 
> commit failed with a message that the folder already existed in the SVN 
> tree.
>
> With the .svn folders created by the add process, the .metadata grew to 59 
> Mbytes!

I have switched from subversion to "git" (although I never had the
problems you describe with subversion, I guess they are mainly due to
eclipse). Git is very fast and efficient, it is used for linux kernel
development so can handle large projects.

Here are some links I bookmarked I found helpful (there may be better
ones now if you do a search):

<http://utsl.gen.nz/talks/git-svn/intro.html>

<http://osteele.com/archives/2008/05/my-git-workflow>

There are tools for importing a subversion repository (with history).

> Now that I've whined about that, has anyone experience with Visual 
> SourceSafe in a version newer than the 6.0?

Sorry, I abandoned 6.0 for svn a long time ago - not tried any newer ones.

[...]


-- 

John Devereux

Hi Scott

I will not suggest to switch systems at this point, simply because I
believe your problems are more fundamental. You'd have similar issues
with other tools.

"Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> writes:

> I'm starting to develop a keen distaste for subversion.  It seems when it 
> works, it works well, but it sure has its perculiarities.  We have used it 
> with both TortoiseSVN and SmartSVN.
>
> For small projects it seems ok.  A recent large project was truly painful. 
> This involved about 100 MS Word docs, a bunch of source files and an Eclipse 
> project.

I am currently maintaining projects with literally hundreds of .PPT
and .DOC and some source files. I am successfully using SVN for
standard source code oriented projects, too.

> Since the Eclipse project had about 35 subprojects, the .metadata 
> folder was quite large.  Most items had been committed as they were done 
> and/or changing.  With the eclipse projects there was a lot of variations on 
> a common project.

I don't put projects into Eclipse's workspace. What is the benefit?

There is also some metadata in the actual project directory.  Try to
find out which files are really project related (e.g. contain compiler
options, etc.) and which files contain silly stuff like "most recent
window layout". Add the latter files to the list in svn:ignore. A web
search might help.

Rule #1: You are not likely the first one to encounter this issue.

> Many of these were created on eclipse by a copy project sequence and
> then renamed.

You were not clear whether you used a file system operation or a SVN
command for that. SVN does have a built-in copy command, which takes
care of that.

>  This caused a surprising side effect.  Each time a project was
> copied, all of the hidden .svn folders were also copied.  I though
> SVN was developed in an eclipse environment, surely it should be
> aware of this.

It's a copy, what did you expect?

> Attempting to add the new projects to the SVN database gave repeated errors. 
> Clean up failed to find or fix the problems. It just failed.  Ultimately the 
> solution seemed to be to get rid of the copied .svn folders, then perform 
> the clean up, then proceed as originally intended.  Painful and tedious and 
> fraught with error.

Yuck!

> The main project .metedata folder took 30 minutes to add to SVN.  Then the 
> commit failed with a message that the folder already existed in the SVN 
> tree.

Split your project into separately managed entities. You called them
sub projects -- treat them as such. Put them into separate
repositories. Use SVN's external references to link them into your
main project.

Regards
-- 
Marcus Harnisch
Consultant

                DOULOS - Developing Design Know-how
    VHDL * SystemC * Verilog * SystemVerilog * e * PSL * Perl * Tcl/Tk  
                  ARM Approved Training Centre (ATC)

Doulos Ltd., Central European Office, Garbsener Landstr. 10, 30419 Hannover
Tel: +49 (0)511 2771340                  mailto: marcus.harnisch@doulos.com
Fax: +49 (0)511 2771349                  Web:    http://www.doulos.com

This e-mail and any attachments  are confidential and  Doulos Ltd. reserves
all rights of  privilege in respect thereof.  It is intended for the use of
the addressee only. If you are not the  intended recipient please delete it
from  your system,  any use,  disclosure,  or copying of  this document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Doulos Ltd is registered in England and Wales: Company No. 3723454. 
Registered Office: Brackley Close, Christchurch, Dorset BH23 6SE, UK.
VAT No: GB 730 3456 59
Directors: Rob Hurley, John Aynsley, David Crowder

On Sep 23, 2:48=A0pm, Marcus Harnisch <marcus.harni...@doulos.com>
wrote:
> .....
> Split your project into separately managed entities. You called them
> sub projects -- treat them as such. Put them into separate
> repositories. Use SVN's external references to link them into your
> main project.
> ...

Anyone please explain what those "project managing" things do which
one cannot normally do using a normal file system - appropriate
directory
trees, appropriate file names etc.

Didi

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Not Really Me wrote:
> I'm starting to develop a keen distaste for subversion.

I'm with Marcus Harnisch in suspecting that you're blaming the messenger 
there.  Neither the perceived adverse side affect of this:

> For small projects it seems ok.  A recent large project was truly painful. 

nor of this:

> Many of these were created on eclipse by a copy project 
> sequence and then renamed.

are really caused by the revision control system as such.  They're 
caused by how you used it.  I.e. this looks like a classical case of 
"Well, don't do that then!".

When you duplicate an existing working copy (a.k.a. sandbox) to start a 
new project, you do _not_ keep the revision control system's own files 
in the copy.  Some systems have special mechanisms for that (e.g. clean 
sandboxes as in "cvs checkout", or copy operations directly on the 
repository so you don't have to copy sandboxes), for others you may have 
to clean up the metadata by hand.

Didi wrote:

> Anyone please explain what those "project managing" things do which
> one cannot normally do using a normal file system - appropriate
> directory trees, appropriate file names etc.

If your file system can be arranged to provide check-in/check-out of the
files to be edited and prevent overwriting of the previous versions by
newer versions, lock access to editing files if someone has already
checked it out of the file-system, then very little. However, if your
file system was capable of those things already then it is not the
normal run-of-the-mill file system.

With management of any project above the very simple level it is
important to arrange the management of the data, documentation, IP and
other files such that it retains its integrity and remains secure. This
means that access to the files for editing purposes has to controlled,
changes to the files need to be tracked and the versioning properly
managed so that any state of the product can be recalled at any point in
time. There are a few extremely good products out there that do just
about the whole job (albeit at a significant monetary cost).

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

"Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message 
news:gbbf8f$a8l$01$1@news.t-online.com...
> Not Really Me wrote:
>> I'm starting to develop a keen distaste for subversion.
>
> I'm with Marcus Harnisch in suspecting that you're blaming the messenger 
> there.  Neither the perceived adverse side affect of this:
>
>> For small projects it seems ok.  A recent large project was truly 
>> painful.
>
> nor of this:
>
>> Many of these were created on eclipse by a copy project sequence and then 
>> renamed.
>
> are really caused by the revision control system as such.  They're caused 
> by how you used it.  I.e. this looks like a classical case of "Well, don't 
> do that then!".
>
> When you duplicate an existing working copy (a.k.a. sandbox) to start a 
> new project, you do _not_ keep the revision control system's own files in 
> the copy.  Some systems have special mechanisms for that (e.g. clean 
> sandboxes as in "cvs checkout", or copy operations directly on the 
> repository so you don't have to copy sandboxes), for others you may have 
> to clean up the metadata by hand.

You are both at least partly correct.  I was on a bit of a rant and I lumped 
a number of things together.  The copied .svn folders/files are really an 
Eclipse problem not an SVN one.  I should also mention that this is not the 
current release of Eclipse, it is a version 3.2.1.  The "perceived" problem 
may well be fixed by now.  Deleting .svn files is not the simplest of tasks 
though.  I found some useful scripts to help with the task, but even that 
took a while when cleaning the workspace .metadata folder.

Scott

On Sep 23, 5:36 pm, "Not Really Me"

> Deleting .svn files is not the simplest of tasks
> though.  I found some useful scripts to help with the task, but even that
> took a while when cleaning the workspace .metadata folder.

I suspect there's an implicit assumption of being able to fall back on
the power of a unix-like shell and associated utilities to deal
with nuisance issues like this...

Not Really Me <scott@validatedqwertysoftware.xyzzy.com> wrote:

> Deleting .svn files is not the simplest of tasks 
> though.  I found some useful scripts to help with the task, but even
> that took a while when cleaning the workspace .metadata folder.

Just export ("svn export") the existing working copy to a new location.
If you start by exporting an existing project directly from the
repository, you don't need any extra cleanup steps.

-a

Not Really Me wrote:
> .....
> Deleting .svn files is not the simplest of tasks
> though.  I found some useful scripts to help with the task, but even that 
> took a while when cleaning the workspace .metadata folder.
> 

What you need is:-

find . -name .svn -exec rm -rf \{\} \;