RE: history shows different login -CVS
Larry, No, but the whole point of CVS is to allow concurrent development in separate sandboxes. Sharing a sandbox is rarely a good idea since you just end up stepping on each others' toes. 1. if CVS is only supposed to allow distributed unreserved - why does it allow personb to commit persona's sandbox? Surely that's a bug. Certainly putting 'persona' as the author when personb committed it defeats part of the value of versioning (unless you change the definition of 'author')? (a/b) 2. if CVS is not the best tool for a shared sandbox with unreserved versioning - what is? One that isn't rubbish, and preferably one that is regularly updated/improved by the vendor based on customer wishes or alternatively one that is open source allowing customers to improve it. 3. if CVS is the best tool - why not accept that and allow it to be extended to better let people get the most out of it? I think tools are there to help me get my job done, and support me how I work. Tools that force their methodology (unnecessarily) on me are generally no help. Your POV is a valid one (and not even uncommon). Tools that are limited to particular narrow methodologies are often very popular - eg: the iPhone. I'm very tempted to 'switch sides' here and agree with your argument... The iPhone is popular because a narrow/clear methodology is generally easier to use with little training - anything you shouldn't do doesn't work. But here the 'argument' gets messy. Whilst many other tools are available - ones that support genuine reserved workflows, or shared sandbox workflows are 'mostly' not open source, and are mostly rubbish (combersome, not client/server, restricted to particular O/S's, haven't been updated in years etc). So in the absence of any alternative, and me being mostly a lazy sod and not wanting to write something from scratch, and me thinking that CVS gets me 80% of the way there - 'I' think/thought the right course is to 'extend' CVS with some (very minor) patches to better suit my workflow (that's the 'real' value of 'free software' for me - the freedom to change it, nothing to do with price). Tony Hoyle and everyone else involved in the project were very surprised when LOTS of people also thought this was a good idea, and began downloading 'CVSNT' in droves and requesting other 'minor' changes that they explained would have a significant beneficial effects on their workflow. I wont list them all for fear of sounding like an advert. So my challenge to you is this: Rather than say do this or don't do that - can you convince the person as to the value of changing their behaviour? If you do 'this' instead you will see 'this' enormous benefit. If they agree with you (that it will be more valuable/helpful for them to work the other way) - I'll happily agree with your position. If they don't agree with you - I'll say the best course is to adapt the software to work they way they want to work. Regards, Arthur A) for shared sandboxes CVSNT has 'cvs edit -A' which sets an O/S ACL on the file so now only the person who 'edited' the file can commit it B) as mentioned in the previous post, CVSNT creates CVSROOT (CVS/Root) strings without the username by default, so the author name comes from the user who commits not the user who created the sandbox. This behaviour is frequently overridden by poorly written GUI's - but that's another topic. P.S. Is this getting seriously off-topic? I'm happy to continue the conversation privately or publicly.
Re: history shows different login -CVS
Arthur Barrett writes: Larry, Or, better still, don't share sandboxes. I hope that comment is in jest? Nope, I'm perfectly serious. Noone still *really* believes that there is only a single valid development workflow or change management methodology do they? No, but the whole point of CVS is to allow concurrent development in separate sandboxes. Sharing a sandbox is rarely a good idea since you just end up stepping on each others' toes. -- Larry Jones I think if Santa is going to judge my behavior over the last year, I ought to be entitled to legal representation. -- Calvin
Re: history shows different login -CVS
Arthur Barrett writes: We always recommend you create the sandboxes using the 'current user' method - then many people can 'share' a sandbox and when each 'commits' it's their 'logged in name' that gets used no the name of the person who created the sandbox. Or, better still, don't share sandboxes. -- Larry Jones This sounds suspiciously like one of Dad's plots to build my character. -- Calvin
Re: history shows different login -CVS
thank you for the input. I still see nothing pointing to the other id. our
CVSROOT on the server where the sandbox is is using
pserver:cvs@host:/repo. I am logged in as build. on server where cvs is
hosted, the pserver is set up with xinted.d as follows:
service cvspserver
{
disable = no
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
group = cvs
log_type = FILE /var/log/cvspserver
passenv = PATH
server = /usr/bin/cvs
env = '$HOME=/repos/cvsroot'
log_on_failure += USERID
server_args = -f --allow-root=/repos/cvsroot pserver
}
So I am not really sure what was done in the past to this working directory.
Funny thing is some of my commits are showing build as the user. It's not
that important, but I'd just prefer that the old id didn't show up. At least
if it was my id or the build id it would be better.
thank you
KM
From: Arthur Barrett arthur.barr...@march-hare.com
To: Larry Jones lawrence.jo...@siemens.com; info...@yahoo.com
Cc: cvs-user-list info-cvs@nongnu.org
Sent: Tuesday, December 4, 2012 6:43 PM
Subject: RE: history shows different login -CVS
KM,
And it caries again depending on the client software. Eg: if you are using
WinCVS, TortoiseCVS or anything else that uses the CVSNT client then it will
depend on the CVSROOT which you used to create the sandbox.
Eg:
- named user: :pserver:km@myhost:/myrepo
- current user: :pserver:myhost:/myrepo
We always recommend you create the sandboxes using the 'current user' method -
then many people can 'share' a sandbox and when each 'commits' it's their
'logged in name' that gets used no the name of the person who created the
sandbox.
Regards,
Arthur Barrett
Product Manager CVSNT
-Original Message-
From:
info-cvs-bounces+arthur.barrett=march-hare@nongnu.org
[mailto:info-cvs-bounces+arthur.barrett=march-hare.com@nongnu.
org] On Behalf Of Larry Jones
Sent: 05 December 2012 08:42
To: info...@yahoo.com
Cc: cvs-user-list
Subject: Re: history shows different login -CVS
KM writes:
This may be a stupid question, but I noticed today that when I
committed/added a new file using a generic build login on my
linux/redhat system, that the history in CVS shows the
previous persons
ID. For example jdoe in history and not build. I can't seem to
figure out how this is assocatied to his ID. This may not
even be a CVS
setting, and may be related to an operating system setting, but I
thought I'd ask anyway.
The user that history records can come from a number of different
places: If you're using an authenticated client/server method like
pserver, it's the username the client sent to the server.
Otherwise, it
comes from getuid() and getpwuid() in the CVS (server) process unless
that's 0. If it is 0, CVS uses the first of getlogin(), $LOGNAME, and
$USER that's set.
--
Larry Jones
Ha! Wild zontars couldn't drag that information out of me!
Do your worst!
-- Calvin
Re: history shows different login -CVS
KM writes: thank you for the input. I still see nothing pointing to the other id. our CVSROOT on the server where the sandbox is is using pserver:cvs@host:/repo. I am logged in as build. on server where cvs is hosted, the pserver is set up with xinted.d as follows: Check the CVS/Root files in your sandbox -- you'll probably find the other id in one of them. CVS uses the stored CVSROOT setting whenever it exists in preference to the default environment variable setting. -- Larry Jones Honey, are we out of aspirin again? -- Calvin's Dad
RE: history shows different login -CVS
Larry, We always recommend you create the sandboxes using the 'current user' method - then many people can 'share' a sandbox and when each 'commits' it's their 'logged in name' that gets used no the name of the person who created the sandbox. Or, better still, don't share sandboxes. I hope that comment is in jest? Noone still *really* believes that there is only a single valid development workflow or change management methodology do they? -Arthur
Re: history shows different login -CVS
KM writes: This may be a stupid question, but I noticed today that when I committed/added a new file using a generic build login on my linux/redhat system, that the history in CVS shows the previous persons ID. For example jdoe in history and not build. I can't seem to figure out how this is assocatied to his ID. This may not even be a CVS setting, and may be related to an operating system setting, but I thought I'd ask anyway. The user that history records can come from a number of different places: If you're using an authenticated client/server method like pserver, it's the username the client sent to the server. Otherwise, it comes from getuid() and getpwuid() in the CVS (server) process unless that's 0. If it is 0, CVS uses the first of getlogin(), $LOGNAME, and $USER that's set. -- Larry Jones Ha! Wild zontars couldn't drag that information out of me! Do your worst! -- Calvin
RE: history shows different login -CVS
KM, And it caries again depending on the client software. Eg: if you are using WinCVS, TortoiseCVS or anything else that uses the CVSNT client then it will depend on the CVSROOT which you used to create the sandbox. Eg: - named user: :pserver:km@myhost:/myrepo - current user: :pserver:myhost:/myrepo We always recommend you create the sandboxes using the 'current user' method - then many people can 'share' a sandbox and when each 'commits' it's their 'logged in name' that gets used no the name of the person who created the sandbox. Regards, Arthur Barrett Product Manager CVSNT -Original Message- From: info-cvs-bounces+arthur.barrett=march-hare@nongnu.org [mailto:info-cvs-bounces+arthur.barrett=march-hare.com@nongnu. org] On Behalf Of Larry Jones Sent: 05 December 2012 08:42 To: info...@yahoo.com Cc: cvs-user-list Subject: Re: history shows different login -CVS KM writes: This may be a stupid question, but I noticed today that when I committed/added a new file using a generic build login on my linux/redhat system, that the history in CVS shows the previous persons ID. For example jdoe in history and not build. I can't seem to figure out how this is assocatied to his ID. This may not even be a CVS setting, and may be related to an operating system setting, but I thought I'd ask anyway. The user that history records can come from a number of different places: If you're using an authenticated client/server method like pserver, it's the username the client sent to the server. Otherwise, it comes from getuid() and getpwuid() in the CVS (server) process unless that's 0. If it is 0, CVS uses the first of getlogin(), $LOGNAME, and $USER that's set. -- Larry Jones Ha! Wild zontars couldn't drag that information out of me! Do your worst! -- Calvin
