[p4] What is a Shelf

[Mark Allender]

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 <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