Branches and Dates
I thought I understood this, but the evidence is against me ... We have a situation where we need to see the state of a branch at a point of time in the past. Problem is that if I checkout the branch and then update ... -D date ... what I appear to get is the state of the module at that date with the branches collapsed. For example, a file that existed only on the trunk mysteriously appears in the branch if I use a date after the time it was added to the trunk. So what are the interactions between branches and dates? #!/mjh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: branch access control
It was my first thought to use cvs status, but this causes a file locking problem: cvs status: [11:04:23] waiting for markh's lock in /tag/dcacvs/CVSROOT I had presumed this was because the temporary file copies (into /tmp) had to be protected from further changes while CVS completed the commitinfo and other housekeeping tasks. Note that this is currently using the pserver in my environment, the situation may well be different for a local repository, or using some other access mechanism. #!/mjh [EMAIL PROTECTED] wrote: - To: Douglas Finkle <[EMAIL PROTECTED]> From: "Mark D. Baushke" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] Date: 09/03/2002 06:44PM cc: Baris Sahin <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: branch access control Hi Douglas, > From: Douglas Finkle <[EMAIL PROTECTED]> > Date: Tue, 3 Sep 2002 13:06:15 -0400 > > Yes, you're right... you can use either of the two methods > mentioned, 'cvs status', or the Entries file. Still, both > of these methods are client side and their success depends > upon software (e.g. Perl) that may or may not be present on > client machines. You are either mistaken or you are running a modified cvs that is not based on the cvshome.org sources. The URL: http://www.cvshome.org/docs/manual/cvs_18.html#SEC167 says: | Note: when CVS is accessing a remote repository, `commitinfo' will | be run on the _remote_ (i.e., server) side, not the client side (*note | Remote repositories::). > I've yet to see a good reason why a patch that passes the > branch tag can't be incorporated into, for example, commit.c > so the rules can be implemented completely on the server side. Putting a 'cvs -Qn status filename' into a commitinfo log loginfo script WILL run on the server side. It works today with versions of cvs going back at least as far as 1.10.5 (the oldest version I had on hand to test with for compatibility just now). > Maybe there's more to it than I'm seeing? It seems likely this is true. Enjoy! -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: (no subject)
I'd come to that belief too, but I was hoping otherwise!Thanks for the URL - I'll see where that gets me.#!/mjh-Baris Sahin <[EMAIL PROTECTED]> wrote: -To: [EMAIL PROTECTED]From: Baris Sahin <[EMAIL PROTECTED]>Date: 09/03/2002 12:05PMcc: [EMAIL PROTECTED]Subject: Re: (no subject)hi,cvs doesnt pass branch information to commitinfo file,so you cant use commitinfo for that.I had the same problem, and then solved with writing a patch for access control. Available at http://www.geocities.com/barissahin/baris--- [EMAIL PROTECTED] wrote: A simple question. Can I discover on which branch a file is being committed from withina script run from the commitinfo file? Basically, I know how to apply per user/module access controls, but I would like to extend this to include branch information so that certain teams are confinedto branches. We have in the past experienced code fixes being applied to thewrong branch and it would be preferable for the technology to help people avoidthat mistake in the future.#!/mjh"wèrû&j)bb²Ò'~/²î¢¸!¶Úþf¢î¢¸?¨¥©ÿ+-wèþ)ß¡ËìDo You Yahoo!?Yahoo! Finance - Get real-time stock quotesú ¾ÉX§X¬´ß¡Ëì{¨®m¶ÿ¨¥{¨®æj)fjåËbú?wèrû
(no subject)
A simple question. Can I discover on which branch a file is being committed from withina script run from the commitinfo file? Basically, I know how to apply per user/module access controls, but I would like to extend this to include branch information so that certain teams are confinedto branches. We have in the past experienced code fixes being applied to thewrong branch and it would be preferable for the technology to help people avoidthat mistake in the future.#!/mjhú ¾ÉX§X¬´ß¡Ëì{¨®m¶ÿ¨¥{¨®æj)fjåËbú?wèrû
RE: CVS and Excel
Title: RE: CVS and Excel Matt, I think 'very' is the word we are looking for here! It has embedded buttons and events that go and get the latest values and perform all manner of HTML publication, manager and QA notification by email, graph plotting and enquiries to other tools providing requirement management and test result tracking etc., etc. A static capture just won't work here, I'm afraid. #!/mjh > -Original Message- > From: Matt Riechers [mailto:[EMAIL PROTECTED]] > Sent: 16 November 2001 13:25 > To: Mark Hewitt > Cc: [EMAIL PROTECTED] > Subject: Re: CVS and Excel > > > > Mark Hewitt wrote: > > > > I have a colleague who wants to derive some code development > > tracking metrics for our CVS hosted products. This needs to > > be done using a Microsoft Excel spreadsheet in a relatively > > automatic way. > > How complicated is the spreadsheet? It could be generated via > script as a > comma-delimited file that Excel could import directly. > > -Matt >
CVS and Excel
Title: CVS and Excel I have a colleague who wants to derive some code development tracking metrics for our CVS hosted products. This needs to be done using a Microsoft Excel spreadsheet in a relatively automatic way. What he would like is to be able to execute CVS commands, or use some DLL or ActiveX type functionality from a Excel VBA to get information back to the spreadsheet. Has anyone done this? (For the record, he is currently checking out to a UNIX area, then building an Oracle database with metrics derived from that area. The Oracle database is then queried using ODBC from Excel VBA. There has to be a better way!) #!/mjh
RE: CVS diff --exclude excluded
Title: RE: CVS diff --exclude excluded Larry, That seems to work! Thanks very much for your time. #!/mjh > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 31 October 2001 21:40 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: CVS diff --exclude excluded > > > Mark Hewitt writes: > > > > In the CVS (1.11.1pl1) source, the GNU option '--exclude' is > > explicitly omitted from the command line parser data structures > > with a comment saying it did not seem applicable for CVS. > > That's because CVS only diffs two files at a time -- the recursion is > handled by CVS, not by diff. > > > The problem is that if this build directory exists when I do the > > 'cvs diff -r ', then the diff aborts telling me there > > is no version in the repository for 'build'. So the ideal fix is > > for me to tell diff to exclude this part of the tree, but I cannot > > because cvs will not pass that one on. > > No, you need to tell CVS to exclude that part of the tree. Have you > tried creating a .cvsignore file in the parent directory that > lists the > build directory? > > -Larry Jones > > Physical education is what you learn from having your face in > someone's armpit right before lunch. -- Calvin >
CVS diff --exclude excluded
Title: CVS diff --exclude excluded In the CVS (1.11.1pl1) source, the GNU option '--exclude' is explicitly omitted from the command line parser data structures with a comment saying it did not seem applicable for CVS. Well, I think I have a need, and I wonder if there are any alternatives or if there is a case for --exclude being parsed with CVS diff. For my automated builds, I need to ascertain if any files have been changed since a tag was applied. I apply tags to record the build identifiers. The build takes place into discrete directory (called 'build') that is created inside the tree by the build scripts I use. The problem is that if this build directory exists when I do the 'cvs diff -r ', then the diff aborts telling me there is no version in the repository for 'build'. So the ideal fix is for me to tell diff to exclude this part of the tree, but I cannot because cvs will not pass that one on. I would find it very difficult to move the build directory out of the check out areas because many things depend on it being there (too many reasons to list here). Similarly, it would be difficult and undesirable to remove this 'build' directory before the diff, again, the reasoning is too long for an introductory request here. So - can the exclude option be put in, or is there another way? #!/mjh
RE: giving up CVS
Title: RE: giving up CVS Take a look at cvswrappers. If you want all files matching a particular filename pattern to have specific commit options, you can define them here. For instance, you could have: *.gif -k 'b' *.jpg -k 'b' etc. #!/mjh -Original Message- From: Marko Faldix [mailto:[EMAIL PROTECTED]] Sent: 14 September 2001 10:23 To: [EMAIL PROTECTED] Subject: giving up CVS Hello, we tried to use jCVS for * LARGE * directory trees consisting of html files and binary files like .gif, .jpg and so on. We consider giving up cvs for our web projects because of the number of problems with large directory trees with mixed files (binary and text). We had binaries which occured as text and so they couldn't be repaired anymore. I studied several days cvs and found out, that binaries can only while importing handled as binary. If forgotten to type in all binary types during import you've lost. Adding a file is a problem for us. If one of us works a day, he will have to add whole parts of new directory trees or many new files - binary and text - in different subdirs. Adding as binary and adding as text is for our purpose very uncomfortable and here is again loss of data in cvs possible because you have to handle cvs which so much care. It was recommended to us to use cvs, but I think by an old unix C programmer who only has to deal with one single text file. What we are looking for is something like CVS but combined with saving data. Using cvs became a safety problem to us. Everything that is stored in cvs has to be saved on third media before. What do you think about that? Are there any web programmers here using cvs with success and how to you save data? -- Marko Faldix M+R Infosysteme Hubert-Wienen-Str. 24 52070 Aachen Tel.: 0241-93878-16 Fax.:0241-875095 E-Mail: [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Remote export failures - reason found!
Finally, I realise why remote exports failed for me. The test for a CVS directory, which labels an area as a work area, takes place in a temporary directory on the server. If you have the TopLevelAdmin option set in the CVSROOT/config file, the test sees the CVS directory created by that command and aborts the export. I regard this as a bug since I don't see why (conceptually) these features should interfere, though from the code I can see that they do. Is there a known fix to this problem, or should I do the cvsbug thing? #!/mjh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cannot export from remote repo to absolute pathname
So what happens the? I presume the client knows that it has a pserver (etc) 'Repository URL' (sic!) and dispatches the appropriate outgoing request. The server performs the specified action into a server side work area (where is that? Can it be configured?) and returns the result to the client. The client then performs a mirror of the server side actions at the client host. Is that right? Where is this documented? How are per-user requests separated at the server side work area? When is the servser side work area cleared? #!/mjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 08 May 2001 19:33 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: cannot export from remote repo to absolute pathname Mark Hewitt writes: > > I have an exactly similar problem (CVS version 1.11, Solaris 2.6). > Looking at the code suggests that the working area check > (i.e., is there a CVS directory here) is done at the server > and not at the client. > > Can this be correct? Yes. The server's working area should be exactly similar [sic] to the client's. -Larry Jones I keep forgetting that rules are only for little nice people. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cannot export from remote repo to absolute pathname
I have an exactly similar problem (CVS version 1.11, Solaris 2.6). Looking at the code suggests that the working area check (i.e., is there a CVS directory here) is done at the server and not at the client. Can this be correct? #!/mjh -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED]] Sent: 26 April 2001 21:47 To: [EMAIL PROTECTED] Subject: Re: cannot export from remote repo to absolute pathname On Wed, Apr 25, 2001 at 06:02:26PM -0600, John E. Hein wrote: > I am trying to export a subtree from a module at a remote repository > to a local directory tree. I tried: > > cvs -d remotehost:/repo_dir export -d /local/dir some_module/sub/tree > > ( cd /local/dir ; cvs -d remotehost:/repo_dir export -d . some_module/sub/tree) > > ln -s /local/dir foo > cvs -d remotehost:/repo_dir export -d foo some_module/sub/tree Export really wants to create the top-level directory. Try this variant of your second case: cd /local rm -r dir cvs -d remotehost:/repo_dir export -d dir some_module/sub/tree -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS setup
(a bit late - sorry!) We manage many InstallShield sources in CVS without any problems. The only thing we try to do (but little goes wrong if we forget!) is to work on the Windows pieces by checking out to windows, and UNIX sources by checking out to UNIX. #!/mjh -Original Message- From: David H. Thornley [mailto:[EMAIL PROTECTED]] Sent: 05 April 2001 18:55 To: Rob Helmer Cc: M Birch; [EMAIL PROTECTED] Subject: Re: CVS setup Rob Helmer wrote: > > Don't check files or directories that have spaces in the names > into CVS. It'll cause nothing but trouble. > I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: tag limits?
This is the way I advocate CVS usage. We use tags of the form 'Build-MMDD-nn' then use a 'Release-NN_MM_XX' tag at the point of release. #!/mjh -Original Message- From: Charles Medcoff [mailto:[EMAIL PROTECTED]] Sent: 02 March 2001 02:05 To: [EMAIL PROTECTED] Subject: tag limits? Hello, I've recently read Martin Fowler's paper on continouous integration (http://www.martinfowler.com/articles/continuousIntegration.html). This paper seems to advocate tagging or "labeling" each build with a build number regardless of whether is is any kind of milestone, release or whatever. The paper also indicates that builds may happen as often as every 10-15 minutes or so. This could result in many, many tags or "labels" being assigned to a given version of a file; could be dozens, or hundreds. Can CVS support this? Is there any limit on tags? Any comments on the whole concept in the context of CVS? Regards, Chuck ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Visual Age and Igloo
The compatibility list for Igloo implies that Igloo works most of the time between visual age and a CVS repository. Does anyone have experience in this area? What works and what doesn't? #!/mjh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Deleted directories reappear in WinCVS
This might be a WinCVS 1.1b14 issue, but I suspect there is something greater happening here! A while ago, I removed a directory from a project because its name only differed in case from a file in the same directory (fine for UNIX, bad for Windows). But I now get failures with WinCVS checkout because it is trying to checkout the long since removed directory. Why is WinCVS trying to checkout a long since removed object? #!/mjh
