[p4] How do YOU identify the code set for a release?

[Jeff A. Bowles]

I believe that, at least up-to-this-point, the commands:   p4 sync a.c b.c
d.c e.c
were, in terms of rpc-calls and database traffic, the same
   as 'p4 sync a.c' and then 'p4 sync b.c' and then ....

As a result, the script that runs
    p4 sync file1#v1 file2#v2 file3#v3 [...]
might be generating a lot more trips to the database than
stuffing the file-list in a label (ultimately, one big operation)
and then sync'ing to that label (another big operation). The
connection-setup overhead isn't that huge, but when multiplied
by a large number of operations, can be significant.

On the second point, it's worth considering running "p4 files"
for debugging, first. I believe that "p4 files #have,#head" and
some variants of that (see 'p4 help undoc' for interesting qualifiers
for specifying revisions) would be useful for you to experiment with.

    -jab

On Jan 8, 2008 11:27 AM, Lloyd Cha <lccha-p4python at naos.org> wrote:

> Hi Jeff
>
> I've been thinking about this a bit more and wondered if you could
> detail what you mean by "less wear-and-tear" on the server.
>
> When sync-ing to a "release" the current method in use here
> essentially collects the list of files and versions required and
> issues something like this:
>
>  p4 sync file1#v1 file2#v2 file3#v3 [...]
>
> as one sync command.  Presumably with labels this could change to:
>
>  p4 sync @label1
>
> It's certainly more convenient to use the label from the command-line
> point of view, and requires fewer bytes of information to be sent from
> the client to the server.  However, it then requires the server to
> lookup information from db.label before actually doing the sync.  So
> there is a trade off here.  Is it more expensive for the server to
> handle the long command line when using individual files, or for the
> server to do the additional lookup in db.label?  Does the server have
> any optimizations that allow syncs to labels to go faster than syncs
> to filelists?
>
> I have another separate question.  If I want to sync my current client
> to a label, but I only want to get the files in the label that are
> newer than the ones I have in my client currently, is there an easy
> way to that?  There's also the problem of files that get added or
> deleted, but I'll think about that later.  I suspect to do anything
> really interesting I'd have to use branches.
>
> I'm actually considering rewriting this script to use labels again,
> but am stil trying to decide if it's worth doing.  When the script was
> written, there was also an issue that p4 labels used to lock more than
> just the db.label file.  Since this is fixed in newer versions, I'm
> hoping that performance of the label lookups would no longer be an
> issue.
>
> Thanks,
> -L
>
> Once upon a time (like on Jan 07, 2008), Jeff A. Bowles wrote:
> > (polite cough)
> >
> > I think that you might find that functionality in one of the P4V
> > "labels" mechanisms, with a whole lot less wear-and-tear on the server.
> >
> >    -Jeff Bowles
> >
> > On Jan 7, 2008, at 11:25 AM, Lloyd Cha wrote:
> > >For better or worse, we use a home-grown script that generates a
> > >"release file list" which defines a list of files and versions that
> > >define a particular release.  This release file is then also checked
> > >...
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com