[p4] Git fusion cached repositories?

[SavageTwinky]

Posted on behalf of forum user 'SavageTwinky'.

I ran into a small issue with git fusion. Since we are just moving to perforce
and git fusion I have an ova I've been messing around and I'm trying to
figure out how to clean up a mess a made.

Since its a sandbox server I jus obliterated all the perforce files from it. But
when I try to push my old git repo it this its stll up to date. I had t rename
my git repo to be able to push it back up. So I'm guessing when I remove the
repositories by obliterating the .//git-fusion and //depot that it didn't
stay in sync with the git-fusion server

Is this something that will eventually be cleaned up or should I manually go
onto the git-fusion server and remove the files.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

No worries; the categories are more like guidelines.

There is a lot of data that is stored in a separate data store in Perforce
called keys. The next time you need to delete a repo there is a delete repo
script in Git Fusion that will do all of the house cleaning for you.

If this is a pure test server I'd recommend nuking it from orbit and
starting again. If there is data you'd like to keep I'd recommend
reaching out to support and they can guide you through the process. I'm not
nearly as experienced in cleaning up Git Fusion as they are.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Duh, I just realized you'll also need to clear out all the git repos in the
home directory of the Git Fusion user. You'll want to ssh into the OVA VM,
switch over to the 'git' user, and then look for the repos in the
.git-fusion directory. Removing those should get you setup to push. The
gf_delete_repo script I mentioned previously normally does that clean up for
you.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[SavageTwinky]

Posted on behalf of forum user 'SavageTwinky'.

Great thanks, it will be good to know for reference but we nuked the server and
started over. It bothers me that gwt gwt-streams and depot are nearly impossible
to delete. On a fresh server I've deleted everything I can possibly delete.
Jobs, Change lists, files, clients, reviews.. and I still had to force delete
them.

So far I think perforce is nifty, but it feels like sometimes things aren't
very transparent. Like wtf is still pointing to my empty
depot!��And after nuking everything I can't submit any file
with my user account because I can't seem to properly set up the git fusion
account.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Ahh, you probably need to run 'p4 snap' on the paths branched from those
deleted depots.

When Perforce branches files we don't copy the archive file in server.
Instead we create what we call a lazy copy which tells the new branch to get its
contents from the original file. This is very handy as it greatly cuts down on
HD usage.

When you obliterate we do not get rid of files that are lazy copied. So
let's say you were to have a depot //foo that you branched to //bar. If you
run 'p4 obliterate -y //foo/...' we won't actually destroy those
archive files since //bar needs them. However that means you can't get rid
of depot foo because technically there is content in there still.

So the trick is to use 'p4 snap'




Quote

snap -- Snap (undo) archive lazy copies (unsupported)
����p4 snap [-n] file[revRange] ... [archivePath]
Snap scans the specified file revisions for any revision that has
an archive file that is a lazy copy.��For each of these files the
contents are copied into their own archive file, and the file is
updated to reflect that it is no longer a lazy copy.
This operation increases the amount of space required for the archive
but ensures that (manually) deleting any other part of the archive
does not affect the specified revisions.
If the archivePath argument is specified, only those file revisions
that have lazy copies of archives in that archive path are copied.
The archive path of a particular file revision can be viewed with
'p4 fstat -Oc' (undocumented).
For example, if you intend to (manually) delete the archives for
'//olddepot', but you know that some number of integrations were
performed from '//olddepot' to '//depot2', you might do
'p4 snap //depot2/... //olddepot/...'
Since 'p4 snap' does not remove the archives from '//olddepot', but
only creates the new archives in '//depot2', you will need to run
'p4 obliterate' on the files in '//olddepot' after you have run
'p4 snap' in order to clean up the '//olddepot' contents.
The -n flag previews the operation without copying files or changing
metadata.
'p4 snap' requires 'admin' access, which is granted by 'p4 protect'.

With no lazy copies to force the files to stick around you can delete your
depot.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[SavageTwinky]

Posted on behalf of forum user 'SavageTwinky'.

Thanks,

Ok so I know this is off topic, but I'm stuck committing stuff, I just
created an ova, blew away everything, added passwords for all the users, and
then set the password in the git-fusion web page. But each time I commit I'm
still getting an error

'GF-change-failed' validation failed:
Git Fusion Submit Trigger user 'git-fusion-user' is not logged in.
Perforce password (P4PASSWD) invalid or unset.

Submit validation failed -- fix problems then use 'p4 submit -c 12109'.
'GF-change-content' validation failed:
Git Fusion Submit Trigger user 'git-fusion-user' is not logged in.
Perforce password (P4PASSWD) invalid or unset.

I then signed into the server, and signed in all the git-fusion-user and
git-fusion-reviews*



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

That's from the Perforce server. Are you using the Perforce server included
in the OVA? If so sign in as perforce and then p4 login as git-fusion-user. That
should do the trick. I'd be happy to go into the sordid details of what all
is happening if you'd like, but that should get you up again.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[SavageTwinky]

Posted on behalf of forum user 'SavageTwinky'.

Details aren't necessary, we actually ran into a problem with our windows
based perforce server importing a 3rd party git repo. So the OVA is a temporary
solution until IT converts everything to Linux.

It didn't quite work. Same error as before while submitting.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[SavageTwinky]

Posted on behalf of forum user 'SavageTwinky'.

I may have removed too much. Are all the depots in the demo deletable, or should
I leave a few?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

All demo data is completely destroyable. It may be easier to spin up a fresh OVA
and start anew, but you should be able to get rid of everything in the depot.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3223-git-fusion-cached-repositories