Source Control - Again

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

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

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

Hi Scott

I will not suggest to switch systems at this po> I'm starting to develop a keen distaste for subversion. It seems when it

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.

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.

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.

It's a copy, what did you expect?

Yuck!

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

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

------------------------------------------------------

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

nor of this:

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.

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

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"

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

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

What you need is:-

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

Michael Chapman wrote: [snip]

Or another approach:

find . -name .svn | xargs rm -rf

-Rich

I would strongly suggest adding a '-type d' in there, just to be on the safe side of things.

And I'm pretty sure "not really" should have a good look at tools designed to help integrate SVN into Eclipse, e.g. Subclipse.

Thanks to all. I did find the find... script. That is how we finally cleaned things up.

I have heard of Subclipse, but as you can tell, haven't used it yet. That might be next weeks chore.

Thanks, Scott

This is a fundamentally wrong approach. Let the source control system keep track of metadata. Do not manually add, destroy or change them. This is the kind of stuff that may change without notice! (And rightly so.)

If you export files, the result should be like if you typed in the files afresh. They should go into a vcs smoothly, and by definition cannot be different from as if you typed the files afresh. If exporting doesn't work this way, you should consider switching to a decent vcs.

Groetjes Albert

--

ned

If you're using Eclipse and Subversion, you need to be using Subclipse. I have considerable experience with this combination with non-trivial repositories and distributed teams, and it works very smoothly (even in 3.2).