Mysterious error
Hello. I am getting the following error message when updating. I have no idea what the problem is. cvs server: Updating .cvs checkout: move away grapevine/docs/graphics/help-terms.gif; it is in the waycvs checkout: move away grapevine/docs/graphics/search.gif; it is in the way Clearly, I don't understand why I have to move these two files and none of the other 200 files. Thanks, Tony
RE: Multiple developers in one work area
I've a new CVS user but an old hand at DEC's CMS code management system. The latter was very good about allowing multiple people in one area. CVS isn't so strong there. I think it is because old-tyme Unix hacks tended to be lone programmers working on smaller projects and therefore didn't need a strong cooperative system. CVS was born because programs were getting more complex and the more traditional businesses were beginning to use Unix. In this Brave New Environment, however, the lone-coder model doesn't work so well. That being said, I think CVS should be used in any event 'cause it is the best thing Linux has, currently, and irritating code management is much Much MUCH better than none at all. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David H. Thornley Sent: Monday, December 18, 2000 10:39 AM To: [EMAIL PROTECTED] Subject: Re: Multiple developers in one work area "Parand T. Darugar" wrote: > > Everything I've read suggests that doing what I want to > do is frowned upon in CVS. My choices are to go with RCS > and not get the benefits of CVS, which I'm loathe to do, > or to build a very simple file locking mechanism alongside > CVS. I'm half way through doing the latter, which will > undoubtedly curse me to hell for breaking the CVS model. > It seems to me that you've already forfeited much of the benefit of CVS by not having the option of individual workspaces. At this point, CVS looks to me something like using a screwdriver as a chisel: it can work, and if you don't have a real chisel it can be the best thing to do, but it isn't going to work as well as a real chisel (if such a thing exists for your case). > A general question to the CVS gurus: it seems a central > assumption of the CVS model is that each developer can > individually build and test the project. This seems limiting. > Is this an understood limit within the model, or am I missing > the whole idea? > I wouldn't describe it as an assumption so much as a goal. CVS is very good at taking large shared projects and allowing each developer to have his or her own copy to experiment and test with. If this isn't going to work, for some reason or another (I've seen some pretty good reasons and some pretty bad reasons), then one of the main reasons for using CVS no longer applies. The thing to remember is that CVS was not intended as the only source code system, but as one that allowed developers to do concurrent development without stepping on each other's feet. It's sufficiently good at various things that people keep applying it in other circumstances (I, for example, put a CVS repository on my Linux box at home, to support single-person development), but I find it difficult to consider that a fault. I think that the correct thing for you to do is to try to find an appropriate tool or adapt a somewhat inappropriate one, and that is what you are doing. -- 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: Branch Merging Behaviour
This happens to us too, most annoying. I have no solution except to avoid checking out old versions of the code. :-P -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Cooper Sent: Wednesday, March 19, 2003 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Branch Merging Behaviour OK, I give up. I'll just have to report this as an issue and see if I can get a response that way. Mark Cooper Mark Cooper 17/03/2003 14:47 To: "Mark Cooper" <[EMAIL PROTECTED]> cc: Subject:Re: Branch Merging Behaviour Is this question not even worthy of the group? Having once again perused the archives I have found this mentioned a few times, but surprisingly not a single response (not even to tell the question poser to RTFM!), not even from the ever entertaining Mr. Jones. Mark Cooper "Mark Cooper" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 17/03/2003 10:11 To: [EMAIL PROTECTED] cc: Subject:Branch Merging Behaviour We have recently noticed a difference in the way that a merge works between two branches and between a branch and the main trunk. Consider the following: branch taken from trunk work proceeds some files removed from trunk (head) new branch taken from trunk working copy updated to new branch first branch merged into new branch What appears to be happening under this scenario is that the files that were removed from the trunk but which still exist in the early branch are re-added into the new branch, then when in its turn the new branch is merged back into the trunk, the files are re-added to the trunk. This has caused us a couple of headaches wondering why removed files kept mysteriously re-appearing on the trunk. This does not occur when doing a merge of a branch into a working copy of the the trunk (head revisions). Is this behaviour correct? I've searched through previous mailing list archives and issue/bug reports, but can't find any reference to this. The manual is particularly obscure about the subject. Mark Cooper Reuse Manager Microlise Limited http://www.microlise.co.uk mailto:[EMAIL PROTECTED] ___ 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Knowing what happens to branches
We're pretty comfortable with CVS here. We have several projects, but a few are large and sometimes there can be 2 or 3 of us working on different parts at the same time. We each make our own branch from a production tag, do our work, and merge the changes back to another branch (or HEAD, depending.) In theory, anyway. We've had a few cases, however, of branches _not_ being merged back onto the mainline for various reasons. What I would like if to be able to know: 1) Why a branch was made 2) The last date a change was made to any file on that branch 3) What branch this branch was merged into 4) When #3 happened I know CVS has some logging capabilities, but I didn't see what I was looking for (with the possible exception of being able to deduce #2) How can I do this? Thanks, Tony ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
What is the proper way to talk to the developers
...and suggest an enhancement. Anyone know how? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS auditing improvement
Recently, we had issues at my company which revolved around CVS branches being forgotten. That is, work was done, but the branches were never merged on to the mainline. While this is a mistake on the developers' part, that is of little comfort to the project manager who is responsible for the result. I did some research and I have not found a good way to audit the lifecycle of a CVS branch. That is, I can't tell when a branch was created, why it was created, and which branch it was ultimately merged with, or when. Or if it was even _supposed_ to be merged back. cvs's history command can give me some of the information, but not all of it. I'll restate my requirements. I want to know 1) when a branch was made 2) why a branch was made 3) who made the branch 4) the disposition of a branch. Is the work good? incomplete? a dead end? 5) the branch into which this branch was merged 6) when the merge happened 7) who did the merge 8) any annotations about the merge 9) any annotations about the branch in general Use case: Assume 1) a module named WTF 2) WTF's current production codeset is tagged REL5. 3) WTF's current fixes are in branch REL5_fixes 4) All work is done remotely using pserver. No one logs directly on to the CVS reposity box. This changes how things are logged in the history, currently. Fred notes that in REL5 of WTF, their company's name is misspelled 20 times. He bugts this using Bugzilla, which tags the issue with id 100. The bug is assigned to developer Stan. Stan creates new branch called "stan_05nov_bugs" which is rooted from REL5. He annotates the creation with "bugz 100 - We can't spell". Stan changes 20 files over the next 2 days. Stan commits the changes, using -m "now we can spell" Stan is assigned another bug, bug 102. Already having a working branch, he elects to use it for 102. He annotes this "Also working on bugz 102 - divide by zero in main.c" Stan fixes the bug in main.c and commits the changes, -m "FYI bug was really in queue.c" Stan calls Mary in testing so she can bless his changes. In the meantime, Stan's hare-brained boss wants changes, which over the next few days turn out to be impossible. This results in... A new branch from REL5 called "harebrained", and annotated as, "perpetual motion patent" the annotation, "No, there was some friction" another annotation, "This branch is dead" His changes are ok'd by the Mary of testing crew a week later. Now he merges "stan_05nov_bugs" into REL5_fixes. He annotates this with "Fixed bugz 100 and 102" --- At this point, the project manager should be able to type a command and see something like: stan,05nov2003,new_branch,stan_05nov_bugs,REL5,"bugz 100 - We can't spell" stan,07nov2003,commit,stan_05nov_bugs,"now we can spell" stan,07nov2003,annotation,stan_05nov_bugs,"Also working on bugz 102 - divide by zero in main.c" stan,07nov2003,commit,stan_05nov_bugs,"FYI bug was really in queue.c" stan,09nov2003,new_branch,harebrained,REL5,"perpetual motion patent" stan,10nov2003,annotation,harebrained,"No, there was some friction" stan,11nov2003,dead,harebrained,"This branch is dead" mary,14nov2003,annotation,stan_05nov_bugs,"works for me" stan,15nov2003,merge,stan_05nov_bugs,REL5_fixes,"Fixed bugz 100 and 102" This is off the top of my head of course, the dates should be full timestamps and so forth. Note the line types - new_branch, commit, annotation, dead, and merge. These relate to the requirements above. They are explicit, and allow the associated comments to fill in the details. Also, imagine 4 developers working on REL5 at the same time - keeping track of the branches might not be so easy. Yadda yadda. But the idea is that we have confidence that the work was done and not left dangling. If the reporting tool above didn't find the "merge" (or "dead") line for a branch, I'd expect to be warned. I'd also expect loginfo/taginfo-like/modules support for the new annotations and so forth. Whew! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Oops I deleted some files
A few days ago I was cleaning up a project and deleted a directory, commited, etc. Now, about a week later, I refetch the project only to find that the directory and the files within were important. Ooops. How do I get them back? I have tried checking out with the date to no avail. The files are still in the Attic on the cvs server. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
