Closed GoogleCodeExporter closed 8 years ago
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 tom.ande...@gmail.com
on 5 Feb 2009 at 1:21
You could do that in one operation via svn move. It'll preserve history etc.
too.
Original comment by cmhena...@gmail.com
on 5 Feb 2009 at 7:32
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 tom.ande...@gmail.com
on 13 Mar 2009 at 3:55
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 jaba...@gmail.com
on 14 Mar 2009 at 2:20
I hopefully fixed this in the latest commit.
Original comment by tom.ande...@gmail.com
on 27 May 2009 at 12:28
fixed
Original comment by tom.ande...@gmail.com
on 27 May 2009 at 12:29
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 cmhena...@gmail.com
on 27 May 2009 at 12:35
@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 jaba...@gmail.com
on 27 May 2009 at 8:04
@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 cmhena...@gmail.com
on 27 May 2009 at 8:19
@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 jaba...@gmail.com
on 28 May 2009 at 4:59
Original issue reported on code.google.com by
cmhena...@gmail.com
on 22 Jan 2009 at 1:48