How to separate stable and unstable versions
Hi All, I've a product. I've to implement many new functions but I'd like to introduce them after I completed. I'd like to separate the stable version from the development version since may be I will have to make changes on the stable as well. Certainly I'd like modifications on the stable version appear in the new version as well so as I don't have to make the same changes on that too, while the partially developed new functions should be hidden for the older version. How can I do such a thing with CVS? I use TortoiseCVS 1.4.5, with cvsnt 2.0.4. Thank you in advance. Best Regards, -- Egyd Csaba --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.528 / Virus Database: 324 - Release Date: 2003. 10. 16. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to separate stable and unstable versions
Együd Csaba wrote: I'd like to separate the stable version from the development version since may be I will have to make changes on the stable as well. One method is to maintain the stable version on a branch, with new features implemented on the trunk. You can periodically merge bug fixes from the stable branch to the trunk, and when you want to release your new features, create a new branch. See the manual for information on branching: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_5.html#SEC54 -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: More case insensitivity issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Okay. Solution #2 it is, to be implemented shortly on stable. Speak now or forever hold your peace if you have objections. Derek Derek Robert Price wrote: | Incidentally, the other side effect of this problem is that *info | scripts running on case sensitive servers are currently passed | incorrectly the names of new added files. Even though file1 might be | resurrected by a command from a case insensitive client, for example, | loginfo could be passed FILE1 as the filename of the new file. | | Either of the solutions below would fix this. Solution 2 by virtue of | making the current incorrect name being passed to loginfo the correct | one without altering it and solution 1, presumably, by correcting the | name in the internal CVS data structures when it was determined that | corrective commands needed to be sent ot the client and before it got | passed to loginfo. | | I'm starting to think I actually prefer solution 2. It is much more | elegant. Any of the consistency buffs out there want to argue with me? | | Derek | | Derek Robert Price wrote: | | | Fixing the assertion failure and repository corruption on an attempted | | recase (remove of file1; add of FILE1) from a case insensitive | | filesystem exposed another bug: | | | | The add now finds the previous version of the file, despite the | | different case, and resurrects it. This is as intended. It is parallel | | to the operation of all of the other CVS commands when run from a case | | insensitive client - it first looks for a file cased as specified and if | | one cannot be found it then finds any file spelled correctly in a | | different case. | | | | The problem is that, on a subsequent update, the case of the entry in | | the CVS/Entries file on the client no longer matches the case of the | | file on the server, which still has the original case. This causes | | move FILE1 - it is in the way errors from the client on updates from | | the server of file1. This is certainly not desirable. | | | | I've been thinking about this problem, and I've come up with two | | possible solutions: | | | | One solution is to keep most of the behavior the way it is, which | | disallows a recase from Windows and other case insensitive clients, but | | send commands on commit of an add to correct the case of the file on the | | client and avoid the in the way errors. I like this solution best, | | since it maintains the behavior parallel to the rest of the CVS commands | | in regards to looking up file requests from case insensitive clients, | | finding differently cased files and assuming that resurrecting those | | files was the intended result. I think this solution will take a little | | longer to implement, | | however, on the order of a week or two of total dev time. | | | | The second solution is to assume that a user performing a `cvs add' from | | a CVS client knows what they are doing when they request a different | | case from any file in the repository and allow the recase, causing an | | add of the new file with the new case. This fix would enable the most | | functionality, but users on case insensitive file systems might be | | surprised by the change in the way the server does file lookups compared | | to the other CVS commands. This fix might or might not require less | | work. Something similar to this was happening before the assertion | | error fix - the first lookup created a new file and a second case | | insensitive lookup determined that there was case ambiguity and an | | assertion failed. I'm sure I could find an alternative way to work | | around this issue, but I'm not sure how long that will take. | | | | I suppose that an argument could be made that assuming the user was | | requesting the case they desired in solution two was actually the same | | behavior expected of the other commands in the case of an add - since a | | file name in any case can be created, any requested case matches | | literally during an add. We don't care during the matching phase | | whether the match happens to cause a create or a resurrection. | | | | Either solution is likely to upset some users. I was hoping to get a | | good feel for how many were on each side of the issue by asking info-cvs | | bug-cvs and maybe even elicit definitive arguments as to why one | | solution should be preferable to the other. | | | | Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- The home town of American Olympic Champion skier, Picabo Street, has decided to recognize their favorite daughter by naming the new wing of the local hospital in her honor. That wing, which will include a state-of-the-art Intensive Care Unit, will hereafter be known as the Picabo, ICU. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
RE: How to separate stable and unstable versions
Hi Matt, I've made a new branch for my stable version and I'd like to continoue the development on the 'main trunk' as the doc mentions it. My problem is that commiting the changes cvs says the following: -- cvs commit: sticky tag `ver1-1-1-2' for file `source/MainForm.dfm' is not a branch cvs commit: sticky tag `ver1-1-1-2' for file `source/MainForm.~pas' is not a branch cvs commit: sticky tag `ver1-1-1-2' for file `source/info.dsk' is not a branch cvs [commit aborted]: correct above errors first! Error, CVS operation failed -- What does it mean and what did I do wrong? Thank you, -- Csaba -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 1:52 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to separate stable and unstable versions Együd Csaba wrote: I'd like to separate the stable version from the development version since may be I will have to make changes on the stable as well. One method is to maintain the stable version on a branch, with new features implemented on the trunk. You can periodically merge bug fixes from the stable branch to the trunk, and when you want to release your new features, create a new branch. See the manual for information on branching: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_5.html#SEC54 -Matt --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.528 / Virus Database: 324 - Release Date: 2003. 10. 16. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 1:52 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to separate stable and unstable versions Együd Csaba wrote: I'd like to separate the stable version from the development version since may be I will have to make changes on the stable as well. One method is to maintain the stable version on a branch, with new features implemented on the trunk. You can periodically merge bug fixes from the stable branch to the trunk, and when you want to release your new features, create a new branch. See the manual for information on branching: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_5.html#SEC54 -Matt --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.528 / Virus Database: 324 - Release Date: 2003. 10. 16. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.528 / Virus Database: 324 - Release Date: 2003. 10. 16. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to separate stable and unstable versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Együd Csaba wrote: |Hi Matt, |I've made a new branch for my stable version and I'd like to continoue the |development on the 'main trunk' as the doc mentions it. My problem is that |commiting the changes cvs says the following: | |-- |cvs commit: sticky tag `ver1-1-1-2' for file `source/MainForm.dfm' is not a |branch As CVS was kind enough to inform you, you are attempting to commit to a sticky tag and not a branch. You should read the section on tags: ~http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_4.html#SEC48 as well as rereading the section on branching: ~http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_5.html#SEC54 Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- Goldfish don't bounce. Goldfish don't bounce. Goldfish don't bounce... ~ - Bart Simpson on chalkboard, _The Simpsons_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/lUI5LD1OTBfyMaQRAoO7AJwOzu1eqScpRlWx2/qIxO33hk8GRQCfY4SR wi/ZjoVml7saDAivqzes4x0= =BJL5 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: setting system users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 kent emia wrote: |hi to all, | |if i would leave the default settings in the config file to |'SystemAuth=no' so this means that the pserver will look into the system |users, right? ~http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_18.html#IDX281 |so in this case how do i restrict users from accessing other projects? ~http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_2.html#SEC13 ~http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_2.html#SEC36 Derek - -- ~*8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! - -- 151. H lp! S m b dy st l ll th v w ls fr m my k yb rd! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/lUPHLD1OTBfyMaQRAmFgAKD+OwoAQmX4Ozg3LObG5hWqarT8PwCfWhyD yDIZAbfqYZkpMLJeoJSFqOM= =R9U5 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to separate stable and unstable versions
Együd Csaba wrote: Hi Matt, I've made a new branch for my stable version and I'd like to continoue the development on the 'main trunk' as the doc mentions it. My problem is that commiting the changes cvs says the following: -- cvs commit: sticky tag `ver1-1-1-2' for file `source/MainForm.dfm' is not a branch You need to move to the branch first, with something like: cvs up -r my_branch_name -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
connecting a proxy cvs server from Ecplise
Hi All:
I have a problem to connecting to a proxy cvs server (linuxos)remote via Ecplise (IDE--window xp). When I try to connect, error message is "cannot locate host". However, I can login this proxy cvs server from terminal window (remote). I did check my /etc/xinetd.d/cvspserver file, passwd file, and hosts file. The following is cvspserver file:
service cvspserver
{
port = 2000
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/usr/local/cvsroot pserver
disable = no
}
when I did a login from ecplise, the following is info I input:
host: hostname
path:/usr/local/cvsroot
username password
use a port 2000 for our case (2401 is blocked by the host).
I read message from internet, I am not sure if firewall will cause this trouble, how do I know that firewall will have an effect on this. The caes is that there is two firewalls, one is in this proxy side, the other in my side through cable modem provider.
Thanks for your help,
Owen
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to separate stable and unstable versions
Hi, I think it has been solved by updating cvs path. The old PATH pointed to the cvs version 1.11.5. The new one points to the expected 2.0.4. My project now seems to be working fine. I can checkout and commit different versions. When I select Branch... menuitem from TortoiceCVS menu TortoiceCVS runs cvs -b -c v1-1-1 Should it add the release as well? -- Csaba -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 3:52 PM To: [EMAIL PROTECTED] Subject: Re: How to separate stable and unstable versions Együd Csaba wrote: Hi Matt, I've made a new branch for my stable version and I'd like to continoue the development on the 'main trunk' as the doc mentions it. My problem is that commiting the changes cvs says the following: -- -- -- cvs commit: sticky tag `ver1-1-1-2' for file `source/MainForm.dfm' is not a branch You created a tag, not a branch. It is good to use a tag to anchor a branch, but now you need to create a branch with the '-b' option to 'cvs tag'. The following would create a branch based on 'ver1-1-1-2': cvs tag -b -r ver1-1-1-2 ver1-1-1-2-branch Note that it may be more useful to name the branch based on a higher-level rev, like 1-1-1 vs. 1-1-1-2; you could then tag the branch as 1-1-1-x if you wanted to make a bug fix release. Adjust the above accordingly. -Matt --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.528 / Virus Database: 324 - Release Date: 2003. 10. 16. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.528 / Virus Database: 324 - Release Date: 2003. 10. 16. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Procedural ways of using CVS.
The approach centers around an enhanced version of the ant CVS Task that is used to create branches and conduct merges. It stores information about branches and tags in a database, and applies it to create the appropriate CVS commands. In practice this custom Task is used twice. The first time, it gets the destination branch into the working directory, tags the source branch (according to a uniform naming convention), and does the update [-j previous-merge-tag] -j current-merge-tag. The output of that operation is watched by what has grown into a slightly complex parser whose job is to flag conflicts. Then you'd do your build and any other tests you want to do. The second use involves committing the merge and tagging the destination branch. [EMAIL PROTECTED] wrote on 10/17/2003 02:51:30 PM: David, Read through your procedure, was quite interesting. Can you tell some more details about ANT and CVS coordination with respect to tagging, merging etc. Thank you. |-+--- | | David Wood | | | [EMAIL PROTECTED] | | | Sent by:| | | info-cvs-bounces+adabalap=schneider.| | | [EMAIL PROTECTED] | | | | | | | | | 10/17/2003 10:50 AM | | | | |-+--- -- | || | To: [EMAIL PROTECTED]| | cc:| | Fax to:| | Subject: Re: Procedural ways of using CVS.| -- | I'll share what I've developed; it may be helpful to you and helpful to me as well, if anyone has comments. Keep in mind that every situation may require a different approach to CVS, and ours is _not_ the most common usage pattern (the most common, I think, focuses on systems or application software development, and that does get some anecdotal treatment in the manual). In my case the job is managing ongoing development of a running Java web application. There are a number of parties who work on various aspects of it in parallel, some off-site. There are generally changes being developed, tested, and ready for deployment simultaneously at a given time. We maintain staging and production branches. The current production branch matches exactly what is deployed at all times. The staging branch is the same, except that it receives new code for testing before it goes to production. Projects happen on Project branches that fork from production when they begin, and merge to staging and then production for testing and deployment. A project may be continuous, or short-lived. If it lives a long time, other changes from the production branch since the fork may be subsequently merged into it. People may share a project, or they may use it alone. We use custom Java code, primarily in several custom ant tasks, to manage merges and the associated tagging automatically, and to integrate this process seamlessly with other aspects of our build and delpoyment process. With one ant task, we can merge, build, and commit that merge if there are no compile errors or conflicts (which we force users to resolve in advance), and then actually push changes to staging and production. It's easy to maintain good logging this way (ant's record task), another bonus. I'm quite pleased with ant's CVS support, and with ant in general. The assumptions in this approach work well for us because our application is fairly compartmentalized. In our case it's important not just to be able to separate out changes by user or project, but to be able to easily put them in (or take them out) of production without affecting other work going on in parallel. Most of all, it's important for us to not have a mystery about what should go in and what shouldn't when it's time to make a new production build (which may happen very frequently), although certainly not every 30 minutes. :) [EMAIL PROTECTED] wrote on 10/17/2003 02:22:53 AM: I'm interested in how people organise their in-house projects from an administrative point of view with CVS, for example, when they use branching, tagging and how (or if) they use CVS with ant, anthill and how they manage frequent builds and releases (ie, every 30 minutes) There is a brief amount of information in the cvs book (Open source dev with CVS), but I'm looking for websites or peoples own opinons on how they structure their in house
Deadline Solaris 9 server help v1.11.5
I have minimal experience with CVS and am seeking some quick install help, guides or scripts to get CVS going on a Solaris 9 server with two initial repositories. Does anything like this exist that anyone can point me to? I'm on a deadline to get this in production for a critical project in a few days. I have skimmed the cederqvist-1.11.6.pdf and have a basic understanding of CVS from a user perspective. I will have local UNIX users using CVS from the command line as well as WinCVS and Tortoise Windows clients accessing the server. I am interested in using pserver authentication, but also wondered if any ssh based authentication mechanisms exist? I'd like to have the users use their existing login credentials supplied by NIS. I doubt this makes much difference VS local UNIX accounts, but thought I'd ask anyway. I was planning to use the cvs-1.11.5-sol9-sparc-local.gz package from www.sunfreeware.com . As well, in addition tot he cederqvist are there any other good documents that will help me administer cvs in my environment? What X-Clients can I get my UNIX users going on? I appreciate any comments, tips, etc. Thanks very much! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: WinCVS
Richard Pfeiffer writes: I have just upgraded from cvs 1.11 to cvs 1.11.9 on my Sun box by installing 1.11.9 to a different location and then changed my PATH setting in my .profile to reflect the new location. I am connecting to it and doing co/ci via wincvs with a pserver connection. When using pserver, the path to CVS is set in the [x]inetd config file, so you'll have to change that to actually used the new version. If you want to run the new and old versions in parallel, you'll have to add a new services to [x]inetd running on a different port. -Larry Jones I don't need to do a better job. I need better P.R. on the job I DO. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: setting system users
kent emia writes: if i would leave the default settings in the config file to 'SystemAuth=no' so this means that the pserver will look into the system users, right? The default setting is SystemAuth=yes (the SystemAuth=no in the config file is commented out), which means that pserver will allow system users. -Larry Jones Temporary insanity! That's all it was! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs performance questions
Good Afternoon, We have been experiencing some slow cvs performance and I had a few quick questions to see if either of these would have any bearing (some of the project directories in the repository are rather large, 357 Mb, etc) 1) If we have multiple users sharing the same userid, would that create any kind of locks, etc, that could hinder co/ci times? 2) There is a great deal of branching taking place, and it has come to my attention that there are some old undeleted tags hanging around. Could enough of these cause a performance issue? Thank you! -R Do you Yahoo!? The New Yahoo! Shopping - with improved product search___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
WinCVS bug
The command-line mode in WinCVS is not behaving correctly. Issuing a command to delete a branch tag failed. I was able to issue the exact same command on Solaris to the exact same server and it succeeded. = Mark Jaffe| (408) 972-9638 (home) Chief Wizard | (408) 807-1530 (cell) Computer Wizards | (425) 795-6421 (FAX) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs performance questions
On Tue, Oct 21, 2003 at 02:10:46PM -0700, Richard Pfeiffer wrote: (some of the project directories in the repository are rather large, 357 Mb, etc) 1) If we have multiple users sharing the same userid, would that create any kind of locks, etc, that could hinder co/ci times? Locks are certainly created, and that will certainly affect co/ci times. But the fact that multiple users share the same userid is irrelevent. (The practice is usually recommended against for reasons of accountability, but it should have no impact on performance.) The overall size of the source tree being operated on will have an effect here. CVS's locking mechanism calls for creating directories and/or files under *every* directory in the repository that's to be visited, *not* just at the root of the subtree of interest. So locking overhead is O(N) on the number of directories in the subtree, not O(1). (But note that I said in the subtree. If you do a cvs co on a leaf directory, i.e. one containing only files, that'll be fast even if the repo as a whole has thousands of directories. Same if you do a cvs co -l on any directory; since it doesn't recurse, it doesn't have to lock the subdirectories.) Of course, as the number of simultaneous users goes up (whether or not they're sharing userids), the likelihood of their contending for the same directories, and thus having to wait for each others' locks, also goes up. 2) There is a great deal of branching taking place, and it has come to my attention that there are some old undeleted tags hanging around. Could enough of these cause a performance issue? Sure, but the value of enough is likely *huge* :-) Tags per se don't take up much space, or, I imagine, much processing time. Deleting old tags is unlikely to have a noticeable effect. (It can make cvs log output less cluttered, at the cost of losing information of course; but DON'T do it merely as a performance measure.) What's more likely to slow things down is performing operations on branches that: - were created many revisions ago - have many revisions on the branch Specifically, the longer the path (along the revision tree) from the revision you're working with to the one at the head of the trunk, the longer the operation will take. See rcsfile(5) for an explanation. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs performance questions
Richard Pfeiffer writes: 1) If we have multiple users sharing the same userid, would that create any kind of locks, etc, that could hinder co/ci times? Not that I can think of. 2) There is a great deal of branching taking place, and it has come to my attention that there are some old undeleted tags hanging around. Could enough of these cause a performance issue? Tags by themselves are very cheap. Branches, on the other hand, can be expensive, since the farther a revision is from the head of the trunk, the more diffs have to be applied to generate it. If you're actively using lots of revisions that are far removed from the head of the trunk, that could explain your performance problems. Of course, the real way to tell is to take some measurements and analyze them to determine the overt cause of the problems: is it excessive I/O, CPU utilization, network latency, or what? Once you know that, you'll have a much better chance of fixing it. -Larry Jones It works on the same principle as electroshock therapy. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvsignore
checking out the CVSROOT from the network will return an error ~$ cvs co CVSROOT cvs server: cannot open /root/.cvsignore: Permission denied cvs server: Updating CVSROOT U CVSROOT/checkoutlist snip ~$ but if i will checkout the CVSROOT in the server theres no error -- kent emia [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
