[p4] What is a Shelf

[Ling Lo]

Jumping in a bit late on this thread, this is exactly what I use shelving
for (I wrote our own Perforce shelf tool with a pretty UI that also unshelfs
to different branches, it only took 2 man days to actually create, I'm
totally shocked by how much CodePickle costs).

Shelving is also useful for unshelving to different machines.  Useful to
those who work from home or need to test a client against a server that
share the same code.  It's also handy as it can be used on any Perforce
server and we have an awful lot of those running at my company and I don't
see that changing until Perforce figures out a way to handle thousands of
users and terabytes of code and data on a single repository.

On 5/17/07, Jeremy Russell <russell_jeremy at yahoo.com> wrote:
>
> The biggest reason I would use this is for code reviews and moving changes
> around from branch to branch, without having to check in. A dev calls says
> that I have a bug in my code, but they are over in some obscure branch. I
> can fix the code were I am bundle it and give it to them so that they can
> apply it there. This is nice in a set of branches were initegrate velocity
> is very slow (a practive I highly recommend no using).
>
> I could also use it to move some significant changes around from one of my
> own client workspace to another one I own.
>
> Given the price on disk space, I think having multiple workspaces is an
> adequate soltuion for the "I have a bug to fix" scenario.
>
> -Jeremy
>
> Mark Allender <marka at volition-inc.com> wrote:
> One reason is that we might have a developer who has half the source tree
> checked out (200+ files) in some major graphical system rewrite. He needs to
> fix a big in the current system. Rather than branch work in progress (or
> branch 200K + files), he can use our equivalent of p4tar (called p4rchive),
> put the stuff on ice, fix the bug, submit, and restore his archive.
> Archiving and restoring could easily take on the order of seconds compared
> to long length of time of doing a branch (not to mention the complexity if
> you wanted to branch in progress).
>
> He could use another workspace, but then it would have to be synced and
> that would take a long time too.
>
> ________________________________
>
> From: perforce-user-bounces at perforce.com on behalf of Rich Ireland
> Sent: Thu 5/17/2007 12:23 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] What is a Shelf
>
>
>
> Why all this talk about a 'shelf' when you can just have a sandbox
> branch already? It seems very odd to me to have a source *control*
> system and want to pass data *around* it. Branching and merging is very
> cheap, very easy, and well understood - what more do you want?
>
> Is this some sort of fear of checking in something that might break a
> build? Again, that's what sandbox branches are for.
>
> Jeff Grills wrote:
> > I'm not so sure that you want to store just the diff - it may be worth
> > storing both the original version and the modified version so that you
> can
> > find a common ancestor from which to apply the diffs to the new tree.
> I'm
> > certainly no expert on 3-way merging, but having just the diff seems
> like it
> > throws away a lot of useful information that could help when applying
> the
> > changes to a different source tree.
> >
> > I seem to remember when I was working on p4tar that there wasn't a way
> that
> > I could get all the revisions that were integrated in order to correctly
> > restore an integrate operation. The problem had something to do with
> > integrating specific revisions and not ranges, like if you manually
> > integrated #1, #3, #5, #7, then the server didn't really indicate that
> in
> > any meaningful way - I think it would show #1-#7, which was wrong. This
> was
> > several years ago, and my memory is terrible, so I've probably gotten
> some
> > of the details wrong. I also seem to remember contact support about the
> > issue and they couldn't find a solution for me either, but I'm not 100%
> sure
> > that actually happened. It wasn't that big of an issue for me, so I
> might
> > have just ignored the issue and moved on. p4tar does have primitive
> support
> > for integrations primarily for code testing on other platforms than the
> one
> > on which the integration was performed, but it just converts the
> resultant
> > integration operations into edits, adds, and deletes.
> >
> > j
> >
> > -----Original Message-----
> > From: perforce-user-bounces at perforce.com
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jeremy Russell
> > Sent: Wednesday, May 16, 2007 9:58 PM
> > To: perforce-user at perforce.com
> > Subject: Re: [p4] What is a Shelf
> >
> >
> > Conceptually this should not be that hard to do. In practice, perhaps it
> is.
> > Get the changes:
> >
> > Get the revision of the file under edit/integrate.
> >
> > Diff the file agianst said revision and get a diff report. p4 diff gets
> > you this in a variety of format. Save the diff off someplace useful. It
> is
> > impotatnt to save the diff, and not the whole file (unless it is a
> binary)
> > so that the change can be applied to multiple branches or different
> verisons
> > of the file.
> >
> > Save all of the source diff in some kind of text based container file.
> > How to store binaries (text based, hex) or keep binaries whole in a
> > container? Suggestions?
> >
> > Add in revision and branch meta data, how the file was being stored,
> > type of change (add, edit, integrate), what else?
> >
> > Package it up into a change bundle.
> >
> > Unpack the bundle:
> >
> > Open the target file for edit/add/integrate - whatever the metadata
> tells
> > us to do.
> > Apply diff.
> > Resolve diff as needed.
> > Over simplification, I know, but the basic idea is there.
> >
> > -Jeremy
> >
> > David Cooper wrote:
> > William thinks correctly. I perhaps shouldn't have used the word "sync".
> > The P4 sync concept did not exist on the system I was using. For our
> main
> > use, which was checking multi-platform builds, it was sufficient just to
> get
> > hold of the same set of changes and use them to check all builds before
> > committing.
> >
> > In this system, a client could "save" a changelist in a "staging" area
> on
> > the server, and other clients could pull those changes, overwriting (and
> > optionally saving) their copies of the files, so that their
> > previous state
> > could be restored easily. Resolving was not an option. The "save" option
> was
> > also used as a backup facility for pending changes.
> >
> > - David
> >
> > Ivey, William wrote:
> >>> -----Original Message-----
> >>> From: perforce-user-bounces at perforce.com
> >>> [mailto:perforce-user-bounces at perforce.com]On Behalf Of
> >>> steve at vance.com
> >>>
> >>>
> >>> Syncing to a pending changelist won't give you the open state of the
> >>> workspace. It will actually only give you the state of the submitted
> >>> depot up to the time the changelist was created. Be careful with
> >>> that. It's not
> >>> what it may appear.
> >>>
> >>> Steve
> >>>
> >> I think he's talking about a feature he'd like added to Perforce
> >> whereby you *can* sync to a pending changelist and get the expected
> >> results - copies of the files as they appear on the other user's
> >> machine. (Of course, it would only be a valid snapshot at the time you
> >> synced.)
> >>
> >> It probably wouldn't be too hard to implement the transfer within
> >> Perforce. The server would get the pending changelist owner's client
> >> to upload the files then pass them down to the client that is syncing.
> >> The trick would be making sense of the operation in terms of more
> >> persistent operations such as real syncs and edits.
> >>
> >> For one thing, it wouldn't be a real sync - it's not aligning your
> >> workspace with the contents of the repository so it breaks the normal
> >> correspondence between the two. It might be reasonable to require that
> >> the files be checked out for editing on both clients since that is the
> >> operation which assumes a difference between the repository and
> >> workspaces. (Of course, if you've checked it out for editing and made
> >> your own changes before syncing, then what? Does it overwrite or does
> >> it force you to resolve?)
> >>
> >> -Wm
> >>
> >> _______________________________________________
> >> perforce-user mailing list - perforce-user at perforce.com
> >> http://maillist.perforce.com/mailman/listinfo/perforce-user
> >>
> >>
> >
>
>
> --
> Rich Ireland
> mailto:r.ireland at computer.org
> Embedded & Real Time Engineering
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
>
> ---------------------------------
> Be a better Heartthrob. Get better relationship answers from someone who
> knows.
> Yahoo! Answers - Check it out.
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>