Question about SVN and the reworked directory hierarchy.

[Leif Mortenson <le...@tanukisoftware.com>]

Sorry if this is obvious. I did an update this morning of the Excalibur
trunk.
SVN went and happily created the new components, deprecated, and
containerkit
directories and checked out all of the files there in. That part makes
sense.

The problem is that SVN left all of the old directories and files right
where they
were. When I look at the trunk with a browser the old directories are no
longer
in the trunk:
http://cvs.apache.org/viewcvs.cgi/excalibur/trunk/?root=Apache-SVN

If I checkout into a clean directory, then I only get the files and
directories that
are in the Trunk.

If I do an update on each of the old directories then they will be
deleted however
it does not appear to be automatic. Selecting all of the directories in
the root
directory and doing an update simply returned that they were up to date.
It seems to have been necessary to do an update on them one by one. :-/

Several directories such as event were failing with errors about the
files not
existing on the server. I had to delete those manually.

My old instrument-client directory had lots of modified files in it. I
backed up
that directory before the update just to be save. It tells me that I
have modified
files but does not give any useful information about the file being
gone. What
would happen if I committed these files? Would they end up in the
correct new
location? I don't want to mess things up. This time, I just manually copied
all of my files over to the new location.

I am using TortoiseSVN. Is this a configuration problem on my part? I am
worried about directories and or files being left around in locations
where it
is not so obvious. Not sure if these are TortoiseSVN problems or general
behavior of SVN in general.

Cheers,
Leif

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

Re: Question about SVN and the reworked directory hierarchy.

[hammett <ha...@uol.com.br>]

----- Original Message ----- 
From: "Leif Mortenson" <le...@tanukisoftware.com>
To: "Excalibur Developers List" <de...@excalibur.apache.org>
Sent: Wednesday, July 14, 2004 12:11 AM
Subject: Question about SVN and the reworked directory hierarchy.


> I am using TortoiseSVN. Is this a configuration problem on my part? I am
> worried about directories and or files being left around in locations
> where it
> is not so obvious. Not sure if these are TortoiseSVN problems or general
> behavior of SVN in general.

Same here. I had to delete the whole trunk and download it again.

Cheers,
hammett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

Re: Question about SVN and the reworked directory hierarchy.

[Peter Donald <pe...@realityforge.org>]

Leo Simons wrote:
> This kind of thing should be working, as svn works with 
> global-revision-number-based changesets, and the changeset for a move is 
> the logical operation "copy A to B; delete A". When you 'svn up', that 
> is what should happen. 

And that is precisely what does happen. However it fails to delete A as 
there were files not under revision control (target/*). Modified files 
also cause the update to fail with a conflict.

If you have locally modified A, subversion will
> not delete it but should issue a warning. You can then commit in the old 
> location, svn up, and the "move" change is merged with the file changes.

this does not occur.

> I guess the basic rule for now is that we do not use 'svn move'.

It is fine - you just need to make sure everyone is aware of the move 
and is given an opportunity to prepare their local stuff.

> Thinking about how to do this better, it is probably best for everyone 
> to coordinate manually, merge in the changes, then create a branch, 
> apply the changes there, then replace the trunk with the branched 
> version...

sounds like way too much work.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

Re: Question about SVN and the reworked directory hierarchy.

[Leif Mortenson <le...@tanukisoftware.com>]

Leo Simons wrote:

> basically its no better than it was with CVS. Sorry again to everyone 
> for causing a mess :-$.

No problem, thanks for doing the work.   Like with CVS, if I know that 
it is a problem with
the tool then I can work around it.  But I had been under the impression 
that this sort of thing
was handled correctly so I assumed that it was something I was doing wrong.

Thanks,
Leif


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

Re: Question about SVN and the reworked directory hierarchy.

[Leo Simons <ls...@jicarilla.org>]

Hi Leif!

Leif Mortenson wrote:
> <snip type="svn problems"/>
> 
> I am using TortoiseSVN. Is this a configuration problem on my part? I
> am worried about directories and or files being left around in
> locations where it is not so obvious. Not sure if these are
> TortoiseSVN problems or general behavior of SVN in general.

This is not good! I had none of the problems you are describing using 
svn 1.0.4 under linux (I did check things would work in a private repo, 
and none of the clients I used had any problems with the move). PeterD 
did have problems as well.

This kind of thing should be working, as svn works with 
global-revision-number-based changesets, and the changeset for a move is 
the logical operation "copy A to B; delete A". When you 'svn up', that 
is what should happen. If you have locally modified A, subversion will 
not delete it but should issue a warning. You can then commit in the old 
location, svn up, and the "move" change is merged with the file changes.

But that does not work. You can not just commit your local changes 
directly. I thought that you could:

cd instrument # before svn up
svn commit -m "Modifications" # changes are merged into the new location
cd ..
svn up # instrument is moved locally, including the changes

This does not work. Instead you need to merge locally. Something like

cd containerkit/instrument
cp -r ../../instrument/* .
svn status # should show your local modifications
svn commit -m "Modifications"
cd ../..
svn revert instrument # rollback your local changes
svn up # with no local changes to instrument, it can be deleted, and
        # svn will do so

I guess the basic rule for now is that we do not use 'svn move'.

Thinking about how to do this better, it is probably best for everyone 
to coordinate manually, merge in the changes, then create a branch, 
apply the changes there, then replace the trunk with the branched version...

# everyone commits all local changes then stops working...
svn copy http://.../trunk http://.../branches/rework
cd ..../branches/rework
svn move X Y
svn delete Z
svn commit -m "restructured"
cd ....
svn delete trunk
svn commit -m "replacing trunk"
svn copy http://.../branches/rework http://.../trunk

basically its no better than it was with CVS. Sorry again to everyone 
for causing a mess :-$.

- LSD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/