From bloqueador.rastreador at localizador.gps.com Thu Apr 3 04:11:59 2008 From: bloqueador.rastreador at localizador.gps.com (bloqueador sem mensalidade) Date: Thu, 3 Apr 2008 00:11:59 -0300 Subject: [cvsnt-dev] 242 http://bloqueadorgsm.vilabol.uol.com.br - Bloqueador gps gsm - localizador gps gsm - sem mensalidade - alarme automotivo , alarme para carros 3785366301383352185870134 Message-ID: Bloqueador ve?cluar com tecnologia gsm - Sem mensalidades Tenha toda seguran?a para seu carro com um pre?o justo. Apenas R$ 299,00 ( sem mensalidades ) http://bloqueadorgsm.vila.bol.com.br/ Compare e Compre. Rastreador de Ve?culo Rastreadores de Ve?culos Rastreador GPS Rastreadores GPS Rastreador Ituran Rastreadores Ituran Rastreador Port?til Rastreadores Port?teis. Assist?ncia 24 Horas Visite agora mesmo nosso site. http://bloqueadorgsm.vila.bol.com.br/ Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores TW4O=Fpx5[q2YEn^3.&VA; K.LhyJ`Axn5AF;3L, From bloqueador.rastreador at localizador.gps.com Thu Apr 3 04:12:06 2008 From: bloqueador.rastreador at localizador.gps.com (bloqueador sem mensalidade) Date: Thu, 3 Apr 2008 00:12:06 -0300 Subject: [cvsnt-dev] 441 http://bloqueadorgsm.vilabol.uol.com.br - bloqueador veicular - localizador veicular - gsm - gps - sem mensalidade 4415371861253276775285704 Message-ID: Bloqueador ve?cluar com tecnologia gsm - Sem mensalidades Tenha toda seguran?a para seu carro com um pre?o justo. Apenas R$ 299,00 ( sem mensalidades ) http://bloqueadorgsm.vila.bol.com.br/ Compare e Compre. Rastreador de Ve?culo Rastreadores de Ve?culos Rastreador GPS Rastreadores GPS Rastreador Ituran Rastreadores Ituran Rastreador Port?til Rastreadores Port?teis. Assist?ncia 24 Horas Visite agora mesmo nosso site. http://bloqueadorgsm.vila.bol.com.br/ Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores Graber - Teletrim - Tele Trim - Ituran - Rastreadores gps , Localizadores, Bloqueadores gC/\nE?!l%]E;LJRmh)xp4'[Cab!Dcw2xJIaQ;TC From arthur.barrett at march-hare.com Mon Apr 28 06:27:10 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Mon, 28 Apr 2008 15:27:10 +1000 Subject: [cvsnt-dev] checkout from cvs.cvsnt.org tags/branches Message-ID: I've updated cvs on cvs.cvsnt.org to the repo version. This new version does a much better job of checking out using the correct version of .directory_history. If you are working on Trunk it probably wont affect your - however if checking out from a branch or tag - files may suddenly appear to go 'missing'. If they do check the rename history since the previous version(s) may have been getting the wrong names when checked out form tag or branch. I think I've fixed most cases of this - but maybe not all. Regards, Arthur From Chuck.Kirschman at Nosp_am.bentley.com Mon Apr 28 21:32:18 2008 From: Chuck.Kirschman at Nosp_am.bentley.com (Chuck Kirschman) Date: Mon, 28 Apr 2008 16:32:18 -0400 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h Message-ID: Here are the fixes for some issues we found when trying to implement a script. This patch is based on the 2.5.3.2382 stable source. I don't know how many of these are fixed on the tip. There are several features/fixes all in one patch so the descriptions are in the order of the changes. Our work was only tested with VB. Take what you like. Cheers chuck 1. Print out line and column number from the script if it fails. Very convenient when creating scripts. 2. Allow a centralized script location defined in the "script.name" file. With many repositories on a single box, making a change to a script that must live in every CVSROOT is an administration nightmare. 3. String was not null-terminated correctly; it was dereferencing char ** as if it was char * 4. Same as 3 5. Putting 11 args into an array of only 9 elements 6. COM says that you give a copy of strings, not the address of your only copy 7. Same as 6 8. Missing AddRef 9. Same as 8 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cvspatch.txt Url: http://www.cvsnt.org/pipermail/cvsnt-dev/attachments/20080428/6a352d19/attachment.txt From arthur.barrett at march-hare.com Mon Apr 28 21:41:36 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Tue, 29 Apr 2008 06:41:36 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Hi Chuck, > script. This patch is based on the 2.5.3.2382 stable source. I don't > know how many of these are fixed on the tip. Can you also send this through as a context diff? "cvs diff -c"? > 2. Allow a centralized script location defined in the "script.name" > file. With many repositories on a single box, making a change to a > script that must live in every CVSROOT is an administration nightmare. What are everyone else's thoughts on this one? One of the reasons why the admin scripts live only in CVSROOT is for security, and if you've chroot jailed CVSNT it can only see it's own 'root'. I suppose if we move this property to /etc/cvsnt/PServer then you'd need root priv to set it anyway - but on windows it's nowhere near as straightforward (and you can't really chroot jail on windows either). All up I'm thinking this sounds a trifle dangerous. Comments? Regards, Arthur Barrett From Chuck.Kirschman at Nosp_am.bentley.com Mon Apr 28 22:27:27 2008 From: Chuck.Kirschman at Nosp_am.bentley.com (Chuck Kirschman) Date: Mon, 28 Apr 2008 17:27:27 -0400 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h In-Reply-To: References: Message-ID: Arthur Barrett wrote: > Hi Chuck, > >> script. This patch is based on the 2.5.3.2382 stable source. I don't >> know how many of these are fixed on the tip. > > Can you also send this through as a context diff? "cvs diff -c"? > >> 2. Allow a centralized script location defined in the "script.name" >> file. With many repositories on a single box, making a change to a >> script that must live in every CVSROOT is an administration nightmare. > > What are everyone else's thoughts on this one? > > One of the reasons why the admin scripts live only in CVSROOT is for > security, and if you've chroot jailed CVSNT it can only see it's own 'root'. > > I suppose if we move this property to /etc/cvsnt/PServer then you'd need > root priv to set it anyway - but on windows it's nowhere near as > straightforward (and you can't really chroot jail on windows either). > > All up I'm thinking this sounds a trifle dangerous. > > Comments? > > Regards, > > > Arthur Barrett > > Context diff sent. I didn't actually change the old behavior; if you want to put the script in CVSROOT then you can. Furthermore, all the other scripting situations such as loginfo run things in other places on the box if you choose. Admittedly they are at different places in the process. For me it's just much better to have a single script on the server when I need to fix a bug. But then most of my servers have about 20 repositories. The proposed implementation forces the "script.name" file to live in every CVSROOT, thus allowing the administrator to make it different per repository if they need to. For example, my test repository runs a test version of the script with additional debugging. It's sort of a poor-windows-user's symbolic link. Thanks chuck From arthur.barrett at march-hare.com Tue Apr 29 00:18:51 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Tue, 29 Apr 2008 09:18:51 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Chuck, >>> 2. Allow a centralized script location defined in the "script.name" >>> file. With many repositories on a single box, making a change to a >>> script that must live in every CVSROOT is an administration nightmare. >> >> What are everyone else's thoughts on this one? >> > Furthermore, all the other scripting situations such as loginfo run things > in other places on the box if you choose. A jail enforces the rule that only things within the jail can be ran (again it's a unix/linux thing, not replicatable on windows) As far as I know CVSNT shouldn't run scripts outside of CVSROOT anyway, but it's a very long time since I looked at all the why's and wherefore's in that area. It certainly is true that if a user has write access to CVSROOT directory in the repo then they may as well be considered root users on the box. If I was giving our CM Design and CVSNT Administration course and someone proposed what you've done with the 'single script location for all repos on a server' I'd ask 'what rule governs when to create a new repository?'. Generally our 'best practice' recommendation is to create a new repo on a server when you need different scripts/rules for the new repo. Security considerations aside - if all these repo's are using the same rules - why not just have one repo (aside from historical reasons)? Each directory can have different ACLs so that can't be the reason - user FRED can be only valid for the module 'project/a' and user MARY can be valid only for the module 'project/b'. The reason why I ask is just that I need to explain to (new) users when they ask me: "when do I use this option 'use same script for all repos'?" versus "when do I create a new repo?". Regards, Arthur From Chuck.Kirschman at Nosp_am.bentley.com Tue Apr 29 15:21:23 2008 From: Chuck.Kirschman at Nosp_am.bentley.com (Chuck Kirschman) Date: Tue, 29 Apr 2008 10:21:23 -0400 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h In-Reply-To: References: Message-ID: Arthur Barrett wrote: > Chuck, > >>>> 2. Allow a centralized script location defined in the "script.name" >>>> file. With many repositories on a single box, making a change to a >>>> script that must live in every CVSROOT is an administration nightmare. >>> What are everyone else's thoughts on this one? >>> >> Furthermore, all the other scripting situations such as loginfo run things >> in other places on the box if you choose. > > A jail enforces the rule that only things within the jail can be ran (again > it's a unix/linux thing, not replicatable on windows) > Fair enough; my servers are currently all Windows. > As far as I know CVSNT shouldn't run scripts outside of CVSROOT anyway, but > it's a very long time since I looked at all the why's and wherefore's in > that area. It certainly is true that if a user has write access to CVSROOT > directory in the repo then they may as well be considered root users on the > box. > That's a bit extreme. They don't need write access to the CVSROOT directory to run a script. In my case, the scripts often send information to a bug tracking software. No write access on the box is required to do that. And access control is through Active Directory groups, so I can control who gets to do what. > If I was giving our CM Design and CVSNT Administration course and someone > proposed what you've done with the 'single script location for all repos on > a server' I'd ask 'what rule governs when to create a new repository?'. > Generally our 'best practice' recommendation is to create a new repo on a > server when you need different scripts/rules for the new repo. > > Security considerations aside - if all these repo's are using the same > rules - why not just have one repo (aside from historical reasons)? Each > directory can have different ACLs so that can't be the reason - user FRED > can be only valid for the module 'project/a' and user MARY can be valid only > for the module 'project/b'. > Of course this was all set up over ten years ago, and originally it was indeed for access control. The problem I saw with ACL's is who gets to decide the access rights. There is no set of administrators for a subdirectory. We have a nice web-based access control mechanism based on AD where two or three users can control who has access to their repository. Think about a company with 200 products. You may be the guy who knows about product 117, and you get to grant read and write access to that repository. I may know about product 45 (but nothing about 117), so I can hand out access to my repository. We really don't want to have a single person or group responsible for handing out access. It's just grunt work, and pointless effort. They'd always have to check with the repository owner before granting the access, and they don't add any value to the process. Furthermore, we need to impersonate the user in order to talk to one of our defect trackers. So we need to run as the committing user. In this circumstance Active Directory permissions are the safest way to go. Another reason to have multiple repositories is load balancing. With your monolithic repository, you are constrained to a single server, and it had better be huge. We have hundreds of Gb's of source in over 140 repositories, spread out over several servers and accessed by over 700 developers. If one repository becomes too big, we can move it to a different server. If several extremely active repositories are on one box and saturate the CPU or network or disk, we can move some of them to different boxes. When products become obsolete, we can pack that repository off and put it on that dusty server in the corner, but still feel confident that the build scripts will work if we need to build it again. We can use cheaper and easier to maintain hardware rather than getting huge iron that is expensive to upgrade or replace. We can even use VM's effectively. So if your company is small or works on just one or two products, the monolithic repository works ok. One of our previous cvs guys is now at another company where that is their approach. He finds that they are pretty much on the verge of needing to move to a "big boy" approach like ours. Access control is poorly managed, the server often bogs down, and backups are an issue. For him, the fact that they use a single repository for their product, web site, and internal database development seems like a bad plan. The only thing these items have in common is that they need to be revision-controlled. We typically take the approach that all servers are set up identically, and that when we need to upgrade a script we would rather do it once per server. Yes, we could programatically inject it into every CVSROOT if we had to, but there doesn't seem to any value in that approach. Now for my opinion. CVS in general seems to be geared at smaller groups. Not as small as VSS, but certainly not large enterprise operations. So your single repository approach, which is aimed at these smaller companies, probably makes sense. Especially if your best practices include turning on auditing. I do not expect any changes or support. I understand what Open Source means. We will continue to submit patches when appropriate that you may accept or reject. > The reason why I ask is just that I need to explain to (new) users when they > ask me: "when do I use this option 'use same script for all repos'?" versus > "when do I create a new repo?". > I'm not sure I understand that question. It's like asking "do I want electric windows" versus "do I want tilt steering?" The answer may be yes or no to either piece independently. You use the same script for all repositories when you want them all to behave the same. If you don't have multiple repositories, then by default you are using the same script for all one of them. In some cases my repository will run the common script and a custom script based on that repository. You create a new repository based on independent sets of source code and/or other considerations, like scripts being different (if you are unable to parse on the module). If your company is small, go with a single repository if you like. If you have multiple products that are reasonably large, then you'll probably want multiple repositories. If you're considering multiple servers, you probably want multiple repositories. Cheers chuck > Regards, > > > Arthur > > > > From arthur.barrett at march-hare.com Tue Apr 29 19:17:52 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Wed, 30 Apr 2008 04:17:52 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Chuck, Thanks again for your time to explain. > They don't need write access to the CVSROOT Yes that is understood. >> Security considerations aside - if all these repo's are using the same >> rules - why not just have one repo (aside from historical reasons)? Each >> directory can have different ACLs so that can't be the reason - user FRED >> can be only valid for the module 'project/a' and user MARY can be valid >> only for the module 'project/b'. >> > Of course this was all set up over ten years ago, and originally it was > indeed for access control. It's already possible to delegate the 'control' permission to a user or group of users for any sub-directory, and whilst we do not provide a web interface the CVS Suite Studio does include a nice graphical way of controlling permissions (in 2.5.04 an evaluation copy/cut down 'cost free' edition of this is included primarily for this purpose). > Another reason to have multiple repositories is load balancing. It's really no harder to move a module than a repository (especially if the administrative scripts are all at the machine level). Your patch is machine specific so it doesn't really help when moving machines - tthough if all machines are organised the same way then in theory the scripts are already on the new machine. Finally 2.5.04 addresses scalability by allowing the admin to set up proxy servers (assuming that the spike loads are mostly read's). > server. Yes, we could programatically inject it into every CVSROOT if we > had to, but there doesn't seem to any value in that approach. The advantage would be in isolation (in the event a hacker compromised the security fewer projects/users would be affected). > Now for my opinion. CVS in general seems to be geared at smaller groups. > Not as small as VSS, but certainly not large enterprise operations. So > your single repository approach, which is aimed at these smaller > companies, probably makes sense. Especially if your best practices > include turning on auditing. Are you suggesting that repository auditing is only an issue for small companies? This feature is generally only required by 100+ user installations. > We will continue to submit patches when appropriate that you may accept or > reject. One of my roles as product manager is to encourage all users to contribute - either by paying for support or by doing what you are doing now - submitting comprehensive bug reports and testing and patches. I personally don't care how people contribute (by cash or in kind) however I do care that people contribute. The only reason why we'll reject a patch is if it is superfluous (eg: if it implements tic-tac-toe, or duplicates existing functionality) or if it represents a security risk. > You create a new repository based on independent sets of source code > and/or other considerations, like scripts being different (if you are > unable to parse on the module). If your company is small, go with a > single repository if you like. If you have multiple products that are > reasonably large, then you'll probably want multiple repositories. If > you're considering multiple servers, you probably want multiple > repositories. What you are saying about multiple servers and multiple repositories has some merit (especially if the CVSROOTs do contain a lot of differences - though that does NOT seem to apply to your org), and the whole reason why CVSNT supports adding multiple repositories is that we did envisage that a user may want multiple repositories (some banking customers require 'chinese walls' where one user not simply denied access to another project but their username is not valid on that project which can only be implemented with multiple repositories). However large org/multiple projects == multiple repositories I think is something that is best actively discouraged - it's not required for any technical reason and steers users to 'native' ACLs or trying to implement security in administrative scripts rather than using the cvsnt native acls. I realize that if we design an idiot proof product only idiots will want to use it, but we still need to give some thought to whether implementing some feature sends the wrong message eg: when we implemented parsable lists of protocol properties some people thought that we wanted CVSROOT to adopt a new syntax and started building CVSROOTs like :protocol:hostname=host;password=passwd:/repo which was never our intention (quite the opposite in fact), but we do some accept responsibility for the misunderstanding since we did implment that feature and did not clearly specify what it was for. Finally whilst your question is about CVSNT we often think in terms of EVSCM (was previously CVSNT 3.x), which does not have RCS files at all but an database on the back end (eg: MS SQL or Oracle). Now whislt it's a bit OT and academic - please humour me: in this new system do your reasons for separate repositories hold up? I do not think so - moving rows in a database is much much more difficult than moving the RCS files around. I suppose you could ask for a separate database for each repo - but since each database has considerable overhead of its own that may not have the desired effect. I'll be very interested in your feedback - particularly about the performance problems that lead to moving a repository to a separate machine - I suspect that the new repository proxies will resolve that. If they do not then I guess you are implying that the load is a write/tag one - and that would be a more serious problem to overcome (particularly in an EVSCM context). Regards, Arthur From tony.hoyle at march-hare.com Tue Apr 29 21:31:58 2008 From: tony.hoyle at march-hare.com (Tony Hoyle) Date: Tue, 29 Apr 2008 21:31:58 +0100 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h In-Reply-To: References: Message-ID: Arthur Barrett wrote: > > I realize that if we design an idiot proof product only idiots will want to > use it, but we still need to give some thought to whether implementing some > feature sends the wrong message eg: when we implemented parsable lists of > protocol properties some people thought that we wanted CVSROOT to adopt a > new syntax and started building CVSROOTs like > :protocol:hostname=host;password=passwd:/repo which was never our intention > (quite the opposite in fact), but we do some accept responsibility for the > misunderstanding since we did implment that feature and did not clearly > specify what it was for. > Originally it was intended that frontends (Mostly Wincvs at that time) could use it for rapid generation of cvsroot strings for random protocols (the keywords match the lists in the 'cvs info' output).. unfortunately the unintended consequence of that was that ended up in the CVS/Root file which caused problems for non-cvsnt based frontends... I quickly realized that it was better to recommend that the CVSROOT be as standard as was possible.. so someone doing a simple pserver checkout wouldn't end up with something incompatible with eg. eclipse. Tony From arthur.barrett at march-hare.com Wed Apr 30 07:21:46 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Wed, 30 Apr 2008 16:21:46 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Chuck, > 1. Print out line and column number from the script if it fails. Very > convenient when creating scripts. > 2. Allow a centralized script location defined in the "script.name" > file. With many repositories on a single box, making a change to a > script that must live in every CVSROOT is an administration nightmare. > 3. String was not null-terminated correctly; it was dereferencing char > ** as if it was char * > 4. Same as 3 > 5. Putting 11 args into an array of only 9 elements > > 6. COM says that you give a copy of strings, not the address of your > only copy > 7. Same as 6 > 8. Missing AddRef > 9. Same as 8 I've made item 2 to require a setting the registry (and added it to the control panel). I've also modified the debug messages so the physical repository name is not revealed unless it's a per-machine location (for security reasons we cant ever display the phsycal repository location in a trace). http://customer.march-hare.com/webtools/bugzilla/ttshow_bug.cgi?tt=1&id=5252 Patch to 2.5.04: http://customer.march-hare.com/webtools/bugzilla/attachment.cgi?tt=1&id=1221&action=view Committed change to 2.5.04 - it will be in the next RC. Regards, Arthur From Chuck.Kirschman at Nosp_am.bentley.com Wed Apr 30 14:28:34 2008 From: Chuck.Kirschman at Nosp_am.bentley.com (Chuck Kirschman) Date: Wed, 30 Apr 2008 09:28:34 -0400 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h In-Reply-To: References: Message-ID: Arthur Barrett wrote: > Chuck, > > Thanks again for your time to explain. > >> They don't need write access to the CVSROOT > > Yes that is understood. > >>> Security considerations aside - if all these repo's are using the same >>> rules - why not just have one repo (aside from historical reasons)? Each >>> directory can have different ACLs so that can't be the reason - user FRED >>> can be only valid for the module 'project/a' and user MARY can be valid >>> only for the module 'project/b'. >>> >> Of course this was all set up over ten years ago, and originally it was >> indeed for access control. > > It's already possible to delegate the 'control' permission to a user or > group of users for any sub-directory, and whilst we do not provide a web > interface the CVS Suite Studio does include a nice graphical way of > controlling permissions (in 2.5.04 an evaluation copy/cut down 'cost free' > edition of this is included primarily for this purpose). > >> Another reason to have multiple repositories is load balancing. > > It's really no harder to move a module than a repository (especially if the > administrative scripts are all at the machine level). > If I move a module to another repository, all the get scripts will now need to check it out from this different repository. Everyone has to reroot or reget their source. If I move a repository including the cname, my users never know it. > Your patch is machine specific so it doesn't really help when moving > machines - tthough if all machines are organised the same way then in theory > the scripts are already on the new machine. > Exactly. > Finally 2.5.04 addresses scalability by allowing the admin to set up proxy > servers (assuming that the spike loads are mostly read's). > >> server. Yes, we could programatically inject it into every CVSROOT if we >> had to, but there doesn't seem to any value in that approach. > > The advantage would be in isolation (in the event a hacker compromised the > security fewer projects/users would be affected). > >> You create a new repository based on independent sets of source code >> and/or other considerations, like scripts being different (if you are >> unable to parse on the module). If your company is small, go with a >> single repository if you like. If you have multiple products that are >> reasonably large, then you'll probably want multiple repositories. If >> you're considering multiple servers, you probably want multiple >> repositories. > > What you are saying about multiple servers and multiple repositories has > some merit (especially if the CVSROOTs do contain a lot of differences - > though that does NOT seem to apply to your org), cvswrappers files are one of the places where repositories vary substantially. One team's binary is another team's text extension. > and the whole reason why > CVSNT supports adding multiple repositories is that we did envisage that a > user may want multiple repositories (some banking customers require 'chinese > walls' where one user not simply denied access to another project but their > username is not valid on that project which can only be implemented with > multiple repositories). > > However large org/multiple projects == multiple repositories I think is > something that is best actively discouraged - it's not required for any > technical reason and steers users to 'native' ACLs or trying to implement > security in administrative scripts rather than using the cvsnt native acls. > > I realize that if we design an idiot proof product only idiots will want to > use it, but we still need to give some thought to whether implementing some > feature sends the wrong message eg: when we implemented parsable lists of > protocol properties some people thought that we wanted CVSROOT to adopt a > new syntax and started building CVSROOTs like > :protocol:hostname=host;password=passwd:/repo which was never our intention > (quite the opposite in fact), but we do some accept responsibility for the > misunderstanding since we did implment that feature and did not clearly > specify what it was for. > > Finally whilst your question is about CVSNT we often think in terms of EVSCM > (was previously CVSNT 3.x), which does not have RCS files at all but an > database on the back end (eg: MS SQL or Oracle). Now whislt it's a bit OT > and academic - please humour me: in this new system do your reasons for > separate repositories hold up? I do not think so - moving rows in a > database is much much more difficult than moving the RCS files around. I > suppose you could ask for a separate database for each repo - but since each > database has considerable overhead of its own that may not have the desired > effect. > > I'll be very interested in your feedback - particularly about the > performance problems that lead to moving a repository to a separate > machine - I suspect that the new repository proxies will resolve that. If > they do not then I guess you are implying that the load is a write/tag one - > and that would be a more serious problem to overcome (particularly in an > EVSCM context). > Again, most of our setup predates cvsNT and ACLs. Maybe we would do it differently if starting today, maybe not. It would just be speculation. You didn't give me any reason why I would want to switch my current setup to a single repository. Unless I would see substantial benefits I would not want to incur the cost. And without trying it I can't say that performance would or would not be adequate. So I'll abstain on that question. As for EVSCM, I really can't say. Until you work with something you don't know where its sharp edges are. Big databases worry me because I can't recover a file from backups without losing all other changes that came after it. I'm not sure what level of hardware would be necessary for a multi-terabyte monolithic repository. On the other hand, it may be incredibly efficient working with a single DB. I just don't know. I really don't feel qualified to comment on a product I've never used. But as you say, it's academic because we're not interested in this route. > Regards, > > > Arthur > > > > From Chuck.Kirschman at Nosp_am.bentley.com Wed Apr 30 16:57:52 2008 From: Chuck.Kirschman at Nosp_am.bentley.com (Chuck Kirschman) Date: Wed, 30 Apr 2008 11:57:52 -0400 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h In-Reply-To: References: Message-ID: Arthur Barrett wrote: > Chuck, > >> 1. Print out line and column number from the script if it fails. Very >> convenient when creating scripts. >> 2. Allow a centralized script location defined in the "script.name" >> file. With many repositories on a single box, making a change to a >> script that must live in every CVSROOT is an administration nightmare. >> 3. String was not null-terminated correctly; it was dereferencing char >> ** as if it was char * >> 4. Same as 3 >> 5. Putting 11 args into an array of only 9 elements >> >> 6. COM says that you give a copy of strings, not the address of your >> only copy >> 7. Same as 6 >> 8. Missing AddRef >> 9. Same as 8 > > I've made item 2 to require a setting the registry (and added it to the > control panel). > If what you're saying is that the script name is stored in the registry, I considered that approach but rejected it as less flexible than the approach used by all the other files (loginfo, commitinfo, etc.) By limiting to one per box rather than on a per-repository basis it made it hard to have groups of repositories, and harder to develop/test because you couldn't set one repository to point to the script you're working on. But it's certainly close enough to meet the administration requirement for us. We only have one script to date. > I've also modified the debug messages so the physical repository name is not > revealed unless it's a per-machine location (for security reasons we cant > ever display the phsycal repository location in a trace). > http://customer.march-hare.com/webtools/bugzilla/ttshow_bug.cgi?tt=1&id=5252 > That sounds good. I mostly needed it for debugging anyway. > Patch to 2.5.04: > http://customer.march-hare.com/webtools/bugzilla/attachment.cgi?tt=1&id=1221&action=view > > Committed change to 2.5.04 - it will be in the next RC. > > Regards, > > > Arthur > Thanks for the update. chuck From andreas.tscharner at metromec.ch Wed Apr 30 17:36:01 2008 From: andreas.tscharner at metromec.ch (Andreas Tscharner) Date: Wed, 30 Apr 2008 18:36:01 +0200 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h In-Reply-To: References: Message-ID: Arthur Barrett wrote: > Chuck, > [snip] >> 2. Allow a centralized script location defined in the "script.name" >> file. With many repositories on a single box, making a change to a >> script that must live in every CVSROOT is an administration nightmare. [snip] > > I've made item 2 to require a setting the registry (and added it to the > control panel). How is this implemented in the unix/Linux version? Best regards Andreas -- Andreas Tscharner andreas.tscharner at metromec.ch ------------------------------------------------------------------------ And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days. -- The Book of Mozilla 12:10 From arthur.barrett at march-hare.com Wed Apr 30 23:04:28 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Thu, 1 May 2008 08:04:28 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Chuck, > If what you're saying is that the script name is stored in the registry, No - it's a boolean setting - it enables or disables this behaviour - by default disabled. Regards, Arthur From arthur.barrett at march-hare.com Wed Apr 30 23:05:38 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Thu, 1 May 2008 08:05:38 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Andreas, >> I've made item 2 to require a setting the registry (and added it to the >> control panel). > > How is this implemented in the unix/Linux version? Registry settings are stored in /etc/cvsnt/PServer on linux. However Chucks patch was to the script trigger only which is a windows only thing for VB scripts. Regards, Arthur From arthur.barrett at march-hare.com Wed Apr 30 23:27:28 2008 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Thu, 1 May 2008 08:27:28 +1000 Subject: [cvsnt-dev] patches for script_trigger.cpp and server.h References: Message-ID: Chuck, > If I move a module to another repository, all the get scripts will now > need to check it out from this different repository. Everyone has to > reroot or reget their source. If I move a repository including the cname, > my users never know it. No not at all - you just handle it identically to how you do now. So you start with everything on 'server' but have the cnames a/b/c/d setup: :pserver:servera:/repo co project/a :pserver:serverb:/repo co project/b :pserver:serverc:/repo co project/c :pserver:serverd:/repo co project/d If you move project/d to a new server (fastbox) then you just move the cname. Eventually I'd like to use the 'publish/advertise' function in cvslock daemon (use 'cvs info -b' for a demo) to automatically find a repo, so the CVS/Root and CVS/Repository would just be ::myproject:: and CVSNT client would just listen for what server is advertising that project and get it from there (since advertising is a broadcast it isn't passed over sub-nets - therefore resulting in each sub-net automatically finding the fastest mirror for any project). The plan also calls for what we refer to as 'multiroot' where CVS/Root and CVS/Repository can have 'multiple roots' so if the ::project:: name cannot be found that the client can then use one of the previously found servers (eg: if you are at a hotel and using a VPN which blocks the multicast advertising). All the hard technical stuff is done - it's just the tedious process of hacking in the changes to CVS itself and the various gui elements. > You didn't give me any reason why I would want to switch my current setup > to a single repository. Mostly I'm trying to ensure I don't add features that encourage people to do the same as you (since it's a lot of work and not necessary). For you there would be a lot of effort in changing back now you've got existing systems running this way - which is one of the reasons I was keen to get the patch added (albeit as safely as possible). I suspect you are doing more work than is needed, and it'll make it harder to take advantage of new features in 2.5.04 such as the repository mirroring which would provide for much more 'ad-doc' capacity building. Splitting up repos prevents teams sharing any common code (though that may not currently be a requirement). > As for EVSCM, I really can't say. Until you work with something you don't > know where its sharp edges are. Big databases worry me because I can't > recover a file from backups without losing all other changes that came > after it. I'm not sure what level of hardware would be necessary for a > multi-terabyte monolithic repository. On the other hand, it may be > incredibly efficient working with a single DB. I just don't know. I > really don't feel qualified to comment on a product I've never used. But > as you say, it's academic because we're not interested in this route. ClearCase, Continuus/CM Synergy and PVCS Dimensions are the three top SCM systems according to Gartner and they all use this monolithic database backend. EVSCM is not for everyone - but the big end of town has consistently chosen SCM tools built this way. Generally I think EVSCM be implemented by companies trying to consolidate various disparate SCM tools already in use (SVN, CVS, CVSNT, MSTS, CC, Dimensions) to a single one that supports 'the best of all' and provides centralised management and auditing and a one-stop-shop for integrations (build etc). Despite not being for everyone - EVSCM is a logical extension to our family of SCM tools and hence why it's important for me to have a consistent message on things like 'many repos' vs. 'one repo'. At the end of the day I don't care how many repos a customer has or sets up (we have the 'multiple repo' function there so people can use it), however I need a clear answer at the ready when they ask me for 'best practice'. Regards, Arthur