Wacky repository layout about openmeta

[GoogleCodeExporter]

Thanks - I never noticed that. I guess to fix it I would issue an svn copy 
command, then delete the openmeta 
stuff under trunk.

Original comment by [email protected] on 5 Feb 2009 at 1:21

[GoogleCodeExporter]

You could do that in one operation via svn move.  It'll preserve history etc. 
too.

Original comment by [email protected] on 5 Feb 2009 at 7:32

[GoogleCodeExporter]

I will do this soon.
Bonus points - what would the command look like? I do this sort of thing rarely 
enough that I always have to 
relearn the details.

Original comment by [email protected] on 13 Mar 2009 at 3:55

[GoogleCodeExporter]

It's more complicated than it should be, I believe, since the root folder of 
the trunk is involved, and one of the sub-folders of the buried "trunk" folder 
(the desired trunk) is named the same as a top level folder from the real 
trunk. (I.e. I believe that "openmeta/trunk/openmeta" will break the move 
operation if you try to put trunk/* 
directly into the root.)

However, I think from within your local svn trunk you can do this set of steps:

svn mv openmeta obsolete-svn-trunk-container
svn ci -m "Moving heirarchy to avoid naming conflict during main move"
svn mv obsolete-svn-trunk-container/trunk/* .
svn rm obsolete-svn-trunk-container
svn ci -m "Moving all desired files and folders into root directory of svn 
trunk, and cleaning up obsolete hierarchy paths"

That should put all the contents of svn/trunk/openmeta/trunk inside svn/trunk 
as desired. (Don't feel bad, 
'cause I didn't have a clue how to make it work at first either. I had to make 
a test repository to test out the 
commands myself. It's a bit of an unusual situation for anyone, I suspect.)

Let me know if that doesn't do what is expected, but a previous more 
complicated attempt, I used the above on 
my test repository and it worked -- except that I forgot to delete the obsolete 
folder before the 2nd commit and 
had to do a 3rd commit. But that's the only difference, so the above should 
work just fine.

Original comment by [email protected] on 14 Mar 2009 at 2:20

[GoogleCodeExporter]

I hopefully fixed this in the latest commit.

Original comment by [email protected] on 27 May 2009 at 12:28

[GoogleCodeExporter]

fixed

Original comment by [email protected] on 27 May 2009 at 12:29

• Changed state: Fixed

[GoogleCodeExporter]

Nope - you have everything in a "trunk" directory under "trunk" rather than 
just a 
single "trunk" directory.  You should do something like this on your repository 
to get 
it to a canonical layout:

    $ svn mv http://openmeta.googlecode.com/svn/trunk/trunk \
        http://openmeta.googlecode.com/svn/trunk1
    $ svn rm http://openmeta.googlecode.com/svn/trunk/trunk
    $ svn mv http://openmeta.googlecode.com/svn/trunk1 \
        http://openmeta.googlecode.com/svn/trunk

I don't know if this would work (it wouldn't with non-svn mv) but if it does, 
bonus:

    $ svn mv http://openmeta.googlecode.com/svn/trunk/trunk \
        http://openmeta.googlecode.com/svn/trunk

Original comment by [email protected] on 27 May 2009 at 12:35

[GoogleCodeExporter]

@cmhenator

That could work except that I'm not sure you can work directly on the remote 
URLs.

I don't think he'd need to do anything to rename and remove the top level 
"trunk". I 
believe a simple "svn mv trunk/* ." from within the top "trunk" directory 
(which is 
probably actually named "openmeta" if he used the Google-suggested checkout 
command) should be sufficient. -- Cleaning up the trunk/trunk folder (which 
should 
then be empty) would be nice too of course.

@tom.andersen

Let's say you started your source code work in (for example) /Users/tom/ on 
your 
system, and originally used the following command to checkout the project 
source 
from Google Code:

svn checkout https://openmeta.googlecode.com/svn/trunk/ openmeta --username 
tom.andersen

Then you should have had created (by svn) a working folder named 
/Users/tom/openmeta/ which contains a "trunk" folder. (Originally, it would 
have 
contained the "openmeta/trunk" path, I believe, before your recent cleanup 
attempt. 
Right?)

So, you should be able to just:

cd /Users/tom/openmeta/
svn mv trunk/* .
svn commit

I believe that will get rid of the "double-trunk" path (i.e. svn/trunk/trunk as 
seen in 
Google Code's source browser view) from the repository.

Of course, this will leave an empty "trunk" folder (that would be 
"/Users/tom/openmeta/trunk" assuming my example working path above) which is 
found in the top level of the project source -- and which you can remove once 
you 
confirm that it is indeed empty (before or after the commit, as you like). But 
it 
certainly should be empty after the svn mv command.

Anyway, that's how I'd probably handle it at this point.

Now whether that's worth ... $0.02 ... $1.00 ... $0.00 ... is your call. :)

Original comment by [email protected] on 27 May 2009 at 8:04

[GoogleCodeExporter]

@jabaker

Subversion works great with repository URLs.

In fact, some operations, like branching and merging, should be performed 
against 
repository URLs and not working copies.

Original comment by [email protected] on 27 May 2009 at 8:19

[GoogleCodeExporter]

@cmhenator

Sorry, I misspoke myself. I really meant something along the lines of "I don't 
know if you can work 
directly on the (root) URL's (of a Google Code source tree repository)" ... 
which should further be read 
to mean that I'm not sure it is advisable.

I don't know enough about what Google Code does behind the scenes with the root 
levels and first 
levels of the hierarchy in each Subversion repository (aka project folder). 
Since they have web interfaces 
to folders there and special bits defining which folders are your "trunk" 
folder (whether it's named 
"trunk" or not, is optional I believe for the project administrator) and 
"branch folder" etc., it could be 
detrimental to mess around with any of the top levels folders without 
understanding what liberties they 
take with hidden files or hard links on their servers etc.

While I'm not aware of any particular limits, caveats, strictures, 
whathaveyou... nonetheless, I personally 
would be hesitant to muck around too much with the top level folders themselves.

Moving files into and out of those folders wouldn't bother me nearly as much as 
actually renaming and 
destroying the original folders such as your suggestion of renaming "trunk to 
trunk1" would do.

So, while you might be able to change them -- and it *might* be entirely safe 
to do so -- I would 
merely recommend against unnecessarily doing so ... particularly when there's a 
similarly simple way to 
move the desired sub-files/-folders around.

Sorry for the confusion of my earlier meaning by not actually addressing my 
concerns... and my poor 
choice of phrasing.

Original comment by [email protected] on 28 May 2009 at 4:59