Creating copies of project with full folder structure leads to misbehaviour when commiting

[jwezel]

Hello,

I've checked out a folder from SVN with Tortoise using Windows
Explorer. In that project folder, I've got several sub folders and
complete directory structures in the subfolders.
In my case, it is
P:\svn-repos\projects\project_template\
which is pointing to the repository path
https://myserver/svn/trunk/projects/project_template/

Now I want to create a copy of the existing project to create a NEW
project. That's why I copy the folder using WinExplorer, assign the
new, correct name
P:\svn-repos\projects\project_CustomerABC\

Then I want to commit my new project to the SVN repository. The
problem is, that the .svn folders are copied as well and there the SVN
path has kept to be the "old" project
https://myserver/svn/trunk/projects/project_template/
Tortoise doesn't realize that the SVN path doesn't match the current
folder name "project_CustomerABC" any more and thinks all is fine. But
it should now target to
https://myserver/svn/trunk/projects/project_CustomerABC/

The current workaround is to remove all .svn-folders in all the
subdirectories, but this task is very boring if I must do it every and
every time again I have to create a new project.

QUESTION/FEATURE REQUEST:
1. I hoped that after a full checkout (or cleanup) of the repository
to my local disc, it detects that there are some "invalid" .svn
folders not matching the current repository and removes the wrong .svn
folders and keeps the other file data so that a next checkin adds the
new files
2. there is a possibility for me to force a cleanup of the .svn
folders somehow else with a 1-click-solution
First choice would be the best one :-)

Thanks for any feedback/ideas!
Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org

[Jean-Marc van Leerdam]

Hi Jochen,

On 10/09/2008, jwezel <jwe...@compumaster.de> wrote:
> Hello,
>
> I've checked out a folder from SVN with Tortoise using Windows
> Explorer. In that project folder, I've got several sub folders and
> complete directory structures in the subfolders.
> In my case, it is
> P:\svn-repos\projects\project_template\
> which is pointing to the repository path
> https://myserver/svn/trunk/projects/project_template/
>
> Now I want to create a copy of the existing project to create a NEW
> project. That's why I copy the folder using WinExplorer, assign the
> new, correct name
> P:\svn-repos\projects\project_CustomerABC\

Wrong. You should NOT move/copy versioned folders like this. There are
special commands available to you for these actions: SVN Copy and
Rename. That will take care of the copy for you and also keep the
history intact.

>
> Then I want to commit my new project to the SVN repository. The
> problem is, that the .svn folders are copied as well and there the SVN
> path has kept to be the "old" project
> https://myserver/svn/trunk/projects/project_template/
> Tortoise doesn't realize that the SVN path doesn't match the current
> folder name "project_CustomerABC" any more and thinks all is fine.

No, you have effectively created two working copies. They can be used
separately to work with the same part of the repository. There is no
implicit relationship between the local root folder of a working copy
and the repository folder it is pointing to.

> The current workaround is to remove all .svn-folders in all the
> subdirectories, but this task is very boring if I must do it every and
> every time again I have to create a new project.

See above for better approach.

--
Regards,

Jean-Marc

----------------
___
// \\ @@ "De Chelonian Mobile"
/ \_/ \/._) TortoiseSVN
<\_/_\_/ / The coolest Interface to (Sub)Version Control
/_/ \_\ Check out http://tortoisesvn.net

[Sam Barnett-Cormack]

jwezel wrote:
> Hello,
>
> I've checked out a folder from SVN with Tortoise using Windows
> Explorer. In that project folder, I've got several sub folders and
> complete directory structures in the subfolders.
> In my case, it is
> P:\svn-repos\projects\project_template\
> which is pointing to the repository path
> https://myserver/svn/trunk/projects/project_template/
>
> Now I want to create a copy of the existing project to create a NEW
> project. That's why I copy the folder using WinExplorer, assign the
> new, correct name
> P:\svn-repos\projects\project_CustomerABC\
>
> Then I want to commit my new project to the SVN repository. The
> problem is, that the .svn folders are copied as well and there the SVN
> path has kept to be the "old" project
> https://myserver/svn/trunk/projects/project_template/
> Tortoise doesn't realize that the SVN path doesn't match the current
> folder name "project_CustomerABC" any more and thinks all is fine. But
> it should now target to
> https://myserver/svn/trunk/projects/project_CustomerABC/
>
> The current workaround is to remove all .svn-folders in all the
> subdirectories, but this task is very boring if I must do it every and
> every time again I have to create a new project.

You probably want to do an "svn export" to create the new project from
the data of the old one. It won't have the history or anything, but you
can use those files for an svn import to the location you want it to
have. There is no relationship between folder names and paths in a
working copy and the paths within the repository on the server.

If you *do* want to keep history, then checkout the whole projects\
folder and do an "svn copy" of the project_template\ folder to
project_CustomerABC\. This may be simpler than doing an export, but it
is limited (AFAIK) to being within the same repository. Export/import
will allow the files to be a clean new start in a separate repository,
if you want that.

Sam

[jwezel]

Hi Jean-Marc,

>There is no
>implicit relationship between the local root folder of a working copy
>and the repository folder it is pointing to.

In daily practice using Tortoise SVN as Explorer-Plugin, the local
folder name and the name in repository is the same. This is since when
you checkin the folders or checkout the folders, the existing folder
names are identical to the local/respository folder name. So, even if
SVN allows in theory using different folder and file names locally and
in repository, in practice it is identical. That's why I'd like to
request a more easy way for syncing local file system with repository
content. (For sure, SVN won't have got a history to these files, but
this is not really required in this case.)

BTW: This request not only applies for stupid copy&paste actions in
windows explorer; also if you're using some tools for working special
things in the folder structure e.g. every night, they typically don't
know anything of SVN, they just copy folders and files and do their
job. But at the end, I'd like those changes to be integrated into my
SVN repository again.

Regards
Jochen

[Dave Lawrence]

jwezel wrote:
> Hi Jean-Marc,
>
>> There is no
>> implicit relationship between the local root folder of a working copy
>> and the repository folder it is pointing to.
> In daily practice using Tortoise SVN as Explorer-Plugin, the local
> folder name and the name in repository is the same.

[...]

Only *inside* the working copy. The name of the directory that the
working copy can be anything, as can the path to it. To change that
behaviour would be restrictive - most users would have to call all of
their working copies "trunk" since this is the directory that you
usually check out. In practice you want to be able to call your w/c
"proj1", "proj2" "another_copy_of_proj1" etc and not be restricted as to
where on the filesystem it lives.

>
> BTW: This request not only applies for stupid copy&paste actions in
> windows explorer; also if you're using some tools for working special
> things in the folder structure e.g. every night, they typically don't
> know anything of SVN, they just copy folders and files and do their
> job. But at the end, I'd like those changes to be integrated into my
> SVN repository again.

If you add files, then they are unversioned until you "svn add" them.
How could subversion possibly know:
a) that you created the file using a copy operation (explorer or otherwise)
b) whether or not you *actually* want to add the files - it doesn't
follow that because you typed copy foo.c foo2.c that foo2.c should
automatically be added

You have to tell it what you want it to do, subversion is very good at
never doing anything you don't ask it to. Therefore, your automated
process *will* have to be subversion aware if they want to do things
with subversion.

Dave

[jwezel]

> If you add files, then they are unversioned until you "svn add" them.

[...]

> Therefore, your automated
> process *will* have to be subversion aware if they want to do things
> with subversion.

Yes, this is the disadvantage of the current situation.
That's why I asked for a support of the Tortoise SVN Explorer plugin
doing all necessary cleanups in my folder structure. ;-)

[Dave Lawrence]

jwezel wrote:
>> If you add files, then they are unversioned until you "svn add" them.
> [...]
>> Therefore, your automated
>> process *will* have to be subversion aware if they want to do things
>> with subversion.
>
> Yes, this is the disadvantage of the current situation.
> That's why I asked for a support of the Tortoise SVN Explorer plugin
> doing all necessary cleanups in my folder structure. ;-)

- Check for modifications
- Click "show unversioned items"
- Select the items and click "add" from the context menu

Don't expect them to add a feature to automatically add files -
subversion simply doesn't make those sort of assumptions - it does
exactly what you tell it to.

BTW if you try and copy, rename or move folders inside your w/c (without
using svn commands) things will really get screwed because the hidden
.svn directories will get moved with them so you've effectively

[Dave Lawrence]

Dave Lawrence wrote:
> jwezel wrote:
>>> If you add files, then they are unversioned until you "svn add" them.
>> [...]
>>> Therefore, your automated
>>> process *will* have to be subversion aware if they want to do things
>>> with subversion.
>> Yes, this is the disadvantage of the current situation.
>> That's why I asked for a support of the Tortoise SVN Explorer plugin
>> doing all necessary cleanups in my folder structure. ;-)
> - Check for modifications
> - Click "show unversioned items"
> - Select the items and click "add" from the context menu
>
> Don't expect them to add a feature to automatically add files -
> subversion simply doesn't make those sort of assumptions - it does
> exactly what you tell it to.
>
> BTW if you try and copy, rename or move folders inside your w/c (without
> using svn commands) things will really get screwed because the hidden
> .svn directories will get moved with them so you've effectively

... something went wrong with sending that message...

yes as I was saying that breaks things. You might like this feature
http://tortoisesvn.net/most-forgotten-feature

[jwezel]

> You might like this feature http://tortoisesvn.net/most-forgotten-feature

This is an absolutely great URL :-) Thx!!
Dave is my personal hero for today *smile*