K-T,

> 	You need to do this with "-t tag" or have current defined
> properly or use "-j" or, preferably, "-k".
> 	-t tag always gets you versions tagged with that label.  This is
> the usual way Stack developers operate, I believe.
>
> 	-j never changes any of your already-setup dependencies.
>
> 	-k doesn't change any dependencies setup with "-r".
I think we want -j in general, and -t occasionally (once we understand 
how eups uses tags). I can't think of a situation where we would want 
-k, unless developing with qserv_testdata, scisql, xrootd, and qserv all 
setup with -r. Which is a situation I almost had, but would've loved to 
avoid via more cooperative eups conditions.

>> What I'm slowly learning is that an eups "tag" means a particular
>> combination of component package versions. So the right thing for
>> qserv is to stamp an eups tag across all packages that qserv depends
>> on, for each merge to master on qserv.
> 	Ideally, this is what buildbot does.  You should use the
> appropriate buildbot tags (bNNN).
Okay, then I need a way to go from a commit on master to the appropriate 
buildbot tag. For example, how may I discover the buildbot tags for the 
DM-666 merge (fb2c1a6ae7) and DM-1055 merge (8ead196)? And how do we 
make sure that qserv_testdata (which buildbot doesn't use?) gets the 
right tag too? I don't think this would have worked 
recently--qserv_testdata isn't available in the main repo.

Do we all have permission to create and manage tags in the server? We 
are all going to make merges to the master branch, and we all need to be 
able to ensure that the right things are tagged.

-Daniel

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1