[p4] What is a Shelf

[Bennett, Patrick]

No, frequently it's when you have code you're currently working on (a
change that will take some time to implement, lots of files open...)
that you need to 'get out of the way' for a brief period of time so that
you can make a quick fix to the existing branch.  You would just shelve
that open changelist (thus reverting those open changes - but your
changes are preserved in the shelf), edit/submit the files you need for
the hotfix, then unshelve the prior changes.  I wrote scripts to kind of
do the same thing with private branches, but branches cause a lot of
problems because they're permanent and get in the way when the same
branch is used over long periods of time for these 'temp' actions.  A
shelf type of system needs to persist the shelf-state, but once
something is unshelved, no history is necessary (or desired).


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Rich Ireland
Sent: Thursday, May 17, 2007 1:24 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 <dcooper at abingdon.oilfield.slb.com> 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