Forums

Source Control - Again

Started by Not Really Me September 22, 2008
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&#2013266166;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 \{\} \;