Jump to content


Remove all revisions but the head one

delete data

  • Please log in to reply
11 replies to this topic

#1 Monops

Monops

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 11 October 2013 - 03:26 PM

Hello!

I'm seeking a way to remove (obliterate) all the revisions for a repository, keeping only the last one. That's a safe thing: I always only need the latest revisioln and keeping more is a massive waste of space.
Do you know how to do this?

Cheers!
Alex

#2 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 14 October 2013 - 04:59 PM

I can't think of a magic incantation to selectively obliterate all but the head revisions. You'll need to write a little script to identify and obliterate the revisions. (oh what I wouldn't give for a head-1 revision specifier).

One you have obliterated the files you should look into the +S filetype; it automatically preserves just the last n revisions. Run 'p4 help filetypes' from the command line for more details.

#3 myocom

myocom

    Member

  • Members
  • PipPip
  • 24 posts

Posted 14 October 2013 - 05:08 PM

View PostP4Matt, on 14 October 2013 - 04:59 PM, said:

I can't think of a magic incantation to selectively obliterate all but the head revisions. You'll need to write a little script to identify and obliterate the revisions. (oh what I wouldn't give for a head-1 revision specifier).

Might I recommend upvoting this p4ideax idea, then? :-)

#4 P4Sam

P4Sam

    Advanced Member

  • Members
  • PipPipPip
  • 484 posts
  • LocationSan Francisco, CA

Posted 18 October 2013 - 09:02 PM

I believe you can do something like:

p4 tag -l templabel ...#head
p4 files "...@<templabel"

to get the effect of #head-1.  (You can't do relative operations on #head directly, but can fake it with a label.)

#5 David Yerkess

David Yerkess

    Advanced Member

  • Members
  • PipPipPip
  • 78 posts

Posted 11 November 2013 - 11:54 PM

If I understand the question properly, to obtain this, I am thinking of using an archive depot.
The -h option allows me not to archive head revisions. This should mean that I can then obliterate all revisions that are not head revisions (maintaining the correct head revision for each branch).

Tests seem to work fine. Would this work or am I missing something?

#6 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 12 November 2013 - 03:30 AM

The one thing that may bite you with an archive depot is the files have to meet very strict constraints to be archived:

Quote


- stored in full (+F) or compressed (+C) format

- not copied or branched from another revision

- not copied or branched to another revision

- located in a local depot


Conveniently if you decide to go with the archive depot though, they have a flag to handle the purges for you:

Quote


The -p flag purges any archives of the specified files in the

specified archive depot. On completion, the action for affected

revisions is set to 'purge'.



#7 David Yerkess

David Yerkess

    Advanced Member

  • Members
  • PipPipPip
  • 78 posts

Posted 12 November 2013 - 10:27 PM

I forgot about the "- stored in full (+F) or compressed (+C) format", but for me that is not a big issue, I'm mainly interested in removing unused revisions of game build files (binary files) and graphic assets such as 3DSMax files.

Regarding the copied/branched from/to, does that mean it must not be the head revision in any location?
If the file was branched and then modified in source and target, would the branched revision be archived?

When the constraints says 'local depot', does that mean stream depot files cannot be archived?
I hope "(not a remote or another archive depot)" is the correct definition.

I knew about the -p flag and incorrectly said obliterate instead of purge.

Thanks,

David

#8 P4Matt

P4Matt

    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 12 November 2013 - 11:40 PM

For the branched/copied state, if a given file is the source of any p4 integ command that resulted in a branch or copy action in cannot be archived. This because the file is used by the target files as a lazy copy. Theoretically you could use 'p4 snap' to break the lazy copy, but that won't help with your disk
usage then. =)

Local just means no remote depots I believe. There shouldn't be any restrictions against stream depot content.

#9 David Yerkess

David Yerkess

    Advanced Member

  • Members
  • PipPipPip
  • 78 posts

Posted 13 November 2013 - 12:20 PM

What I mean is, say I have:
//productA/main/image.jpg#1 which I branch to //productA/build1/image.jpg#1
//productA/main/image.jpg#2 which I branch to //productA/build2/image.jpg#1
//productA/main/image.jpg#3 which I branch to //productA/build3/image.jpg#1

After obllterating //productA/build2/... I can archive //productA/main/image.jpg#2 correct?

My idea is maintaining build branches in this manner:
  • I create daily branches from the main branch
  • when a milestone (i.e. prototype, alpha, beta, etc.) is reached and approved, all older daily branches are removed (obliterated) leaving only the milestone branch and the main branch
  • archive all file revisions that are not head revisions (-h option)
  • purge archive files (-p option)
  • at the end of the project remove all milestone branches leaving only main and release branches

Do labels influence the archive command?

Thanks,
David.

#10 P4Rusty

P4Rusty

    Member

  • Members
  • PipPip
  • 20 posts

Posted 13 November 2013 - 04:45 PM

A MUCH more efficient process would be to just label main each time you
build using automatic or autoreload labels, and then, at the end of your
project, remove all of the labels that you don't want. Only branch when you
need to do parallel development.

Regards,
Rusty



On Wed, Nov 13, 2013 at 4:25 AM, David Yerkess <
perforce-user-forum@forums.perforce.com> wrote:

Quote


Posted on behalf of forum user 'David Yerkess'.

What I mean is, say I have:
//productA/main/image.jpg#1 which I branch to //productA/build1/image.jpg#1
//productA/main/image.jpg#2 which I branch to //productA/build2/image.jpg#1
//productA/main/image.jpg#3 which I branch to //productA/build3/image.jpg#1

After obllterating //productA/build2/... I can archive
//productA/main/image.jpg#2 correct?

My idea is maintaining build branches in this manner:

-  I create daily branches from the main branch
-  when a milestone (i.e. prototype, alpha, beta, etc.) is reached and
approved,
all older daily branches are removed (obliterated) leaving only the
milestone
branch and the main branch
-  archive all file revisions that are not head revisions (-h option)
-  purge archive files (-p option)
-  at the end of the project remove all milestone branches leaving only
main and
release branches


Do labels influence the archive command?

Thanks,
David.



--
Please click here to see the post in its original format:
http://forums.perfor...ic/2807-remove-
all-revisions-but-the-head-one
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user




--
Rusty

775-636-6964 Office
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user



#11 David Yerkess

David Yerkess

    Advanced Member

  • Members
  • PipPipPip
  • 78 posts

Posted 13 November 2013 - 07:38 PM

Each milestone would be branched, because changes might be required for the milestone, whilst normal development continues.
Then we have the release branches for each platform (PC, PS3, Xbox360, PSVita, PS4, XboxOne), plus resubmissions and patches.
This means something like 10-20 branches that will remain after the end of the project

I really don't want two different methods for people to work with the build versions.

Also, honestly, I don't like the way labels work. Most probably I haven't enough experience, but I found them difficult to work with within P4V.
I can't see the files in a label (from P4V). Actually I think I did once, but don't seem to be able to anymore.
I managed many time to remove files from my workspace, because they weren't part of the labels view, when what I wanted was a clean situation within the labels view.

If we have daily branches, but then they are obliterated, will that be giving us problems?

Thanks,
David

#12 P4Rusty

P4Rusty

    Member

  • Members
  • PipPip
  • 20 posts

Posted 13 November 2013 - 11:10 PM

If you are going to create that many branches, I highly recommend you set
your project up as streams and make all of your branches as task streams.
Task streams use just in time branching and will prevent your database from
growing too quickly due to all of the branching.

Regards,
Rusty



On Wed, Nov 13, 2013 at 11:40 AM, David Yerkess <
perforce-user-forum@forums.perforce.com> wrote:

Quote


Posted on behalf of forum user 'David Yerkess'.

Each milestone would be branched, because changes might be required for the
milestone, whilst normal development continues.
Then we have the release branches for each platform (PC, PS3, Xbox360,
PSVita,
PS4, XboxOne), plus resubmissions and patches.
This means something like 10-20 branches that will remain after the end of
the
project

I really don't want two different methods for people to work with the build
versions.

Also, honestly, I don't like the way labels work. Most probably I
haven't enough experience, but I found them difficult to work with within
P4V.
I can't see the files in a label (from P4V). Actually I think I did once,
but don't seem to be able to anymore.
I managed many time to remove files from my workspace, because they weren't
part of the labels view, when what I wanted was a clean situation within
the
labels view.

If we have daily branches, but then they are obliterated, will that be
giving us
problems?

Thanks,
David




--
Please click here to see the post in its original format:
http://forums.perfor...ic/2807-remove-
all-revisions-but-the-head-one
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user




--
Rusty

775-636-6964 Office
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user







Also tagged with one or more of these keywords: delete, data

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users