Re: Limitation on --allow-root pserver options?
You could consider using xinetd alongside Solaris inetd (just for the CVS
port). It would be a simple experiment to set it up and see if it, too,
exhibits the problem.
[EMAIL PROTECTED] wrote on 12/02/2003
03:38:25 AM:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark [EMAIL PROTECTED] writes:
We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script
in /etc/inetd.conf to allow many --allow-roots (we have many
apps/groups/business units we provide CM support for, thus the need to
many repos). We use WinCVS 1.3 for the client.
Okay. However, there are many bug fixes to cvs available in the latest
cvs 1.11.9 version of cvs.
Currently we have 58 --allow-root options setup in the wrapper script.
The 58th --allow-root does not work/is not recognized.
When we try to login via pserver:
- the client gets no such repository message
- the server logs a login refused for in /var/adm/messages
When I moved that 58th -allow-root to the top of the -allow-root list,
it worked, but then the new last one in the list, now has the above
described issues.
Well, clearly some problem is being uncovered. If you are able to
upgrade to a newer version of cvs and still have the problem, then
it may be possible to help you debug the problem on this list.
Is this a solaris limitation or a cvs limitation (there are about 2513
characters that make up the --allow-root argument string, excluding
any
spaces)?
I am not aware of such a limitation, however, you could test it
yourself.
Take a simple program like this:
% cat testit.c
#include stdio.h
int main(int argc, char *argv[]) {
int i; for ( i = 0; i argc; i++ ) printf(%d: %s\n, i, argv[i]);
return(0);
}
%
Compile it and give it all of the arguments you setup in your wrapper
script for cvs and see what happens.
I could use different ports on the server to balance out the
repositories but WinCVS 1.3 doesn't retain port info inside the
CVS admin subdirectory files in the workares which causes problems
for users who have to work out of repos on different ports at the same
time. (ie. instead of WinCVS 1.3 gathering all it needs from a
workarea's CVS subdir to commit/update etc... it uses the current port
settings in the WinCVS preferences regardless of what the workarea is
currently being used this is quite annoying and confusing)... if
this issues has been fixed in WinCVS 1.3, please let me know.
Any help/insight/suggestions is appreciated. yes we only have one
solaris server to use, and yes we must have independent
repositories..
Thanks,
Mark
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/zE+B3x41pRYZE/gRAsJMAJsGOsCUaYAUE++6sIWazSnGfHTV9ACdFVck
Lyqb6jf6h+thjyzNIlIJkUY=
=3nB/
-END PGP SIGNATURE-
___
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: Please help..
Two things. First, did you work for 18 months on something without making backups? If you never made backups, then whether it was a mistake setting up CVS, some other kind of mistake, hardware failure, fire, or theft, you were destined to lose your work. I hope, however you resolve this issue, that you will always make nightly backups in the future. If you are ahead of me, and you have backups after all, then you can always use them to undo whatever you've done. I'm guessing, but at this point it may be easiest. Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. [EMAIL PROTECTED] wrote on 11/26/2003 11:32:10 AM: Hi All, I am seriously new to CVS. I have a large project that has been developed by my self for the past 18 months but is about to be taken on by a few other people so I though CVS would be a good way of working. I seem to have turned all of my original source files within the directory to have a .v extention and a lot of stuff has been added to these files. Please tell me their is an easy way to get my files back! I seem to have figurered out now how to make a repository from my original source files but they all have a double .v (.v.v) file extention now!!! Doh. Thanks in advance!! Cheers John ___ 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: Please help..
You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT stuff etc. My source files are in /home/johnwards/www/sportnetwork I thought I should have done this: CVSROOT=/home/johnwards/www export CVSROOT cvs init Then: cvs import -m SportNetwork first import -d sportnetwork sportnetwork start This was wrong :-( I think. As its changed all my files... I am really confused by the manual...all I want to do is set up CVS using my source files...how on earth do you do it as I am really confused.. John ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Is the problem that you're not sure how to get the network drive into the sshd filesystem root? Or that when you try to that it fails? If it were the latter, it would be reminiscent of a similar problem I had trying to get apache to serve files from a network drive on Windows XP. We found that the Local System Account that the apache service ran under by default did not have permissions to access the drive. If you were having trouble with it, you might look into what user the sshd process is running as, and whether that user has permission to access the drive. [EMAIL PROTECTED] wrote on 11/26/2003 02:25:14 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I settled on a compromise for the nonce. I fixed the latest case insensitivity bug I knew of in 1.11.x and removed case insensitivity support from feature entirely. I've also added some tests of behavior involving heterogeneous combinations of case sensitive and case insensitive clients and servers to both branches though I've yet to get it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). Since things look stable without case insensitivity support, I will probably remove support from stable too if any new bugs crop up. I'll probably roll a new release early next week. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD DIdO/rpFI8YlFAqUrOukha4= =q+r2 -END PGP SIGNATURE- ___ 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: Please help..
I had the same thought, Steve, and I think the same concern - given what he did, the repository _might_ have been a valid one the first time through - and it might be a valid repository of the repository now. But without knowing the nuts and bolts of the repository and import process, I can think of reasons why it wouldn't be. Of course, there's not much to lose in performing the experiment, as long as you take care and keep copies of everything. I'll be curious to hear if following these instructions would work. [EMAIL PROTECTED] wrote on 11/26/2003 02:46:10 PM: David, Perhaps John could try this? A suggestion to untangle: 1. Create a repository properly. 2. Copy the .v.v files into the repository manually. 3. Checkout the files into a working directory. (getting a .v file) 4. Copy the .v files manually into the repository. 5. Checkout the files into a working directory. (hopefully getting back the originals.) This assumes that the creating the repository over the original files didn't muck them up too much. John, Don't just try the above suggestion till we get more input. I'm just floating an idea and I think the experts here might have something more to say about it. Understanding how the repository is different from the working directory is crucial. A few clif notes: * You create a repository in an empty directory. This repository is separate and very different from the data you actually work on. In our case our repository is in /swdev/cvsroot. This is what the CVSROOT environment variable is set to. * You use ONLY cvs commands to get data into and out of the repository. Ideally you'd never directly touch the repository data. * You work in a separate working directory (off of your home directory probably, in my case /home/derosier/projects) and you check out your source code modules there. When you've made some changes you want to check in, you do a 'cvs commit' command. * Even if you run CVS locally, think of it as a server. It's a black box where you store things. You make requests to get data out, work on it, and then make a request to store data back in. From an OOP point of view: It is encapsulated data with a very well defined interface or API. Use the interface, don't touch the data. * If the above doesn't make sense to you, then read it again, read the CVS manual again until it makes sense. Do not try to setup and use CVS without understanding this. Hope this helps, - Steve David Wood wrote: You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT
Re: CVS merge
I think the problem is the start and end points of your merge. If I have a trunk, and I created a branch from that trunk, tagging it at the point it was created, I would use the following to merge the branch back into the trunk: -j branch_CREATED -j branch Often this can simply be abbreviated as -j branch If you are doing something more complicated than this, please tell us the structure of the branches involved. There are additional details on this subtle and complex feature here, in the manual under the Branching and Merging section: http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_5.html#SEC54 I advise you to read it carefully, or you will get into trouble. [EMAIL PROTECTED] wrote on 11/11/2003 09:23:19 PM: Hi, I don't think my following merge result is correct. I did a merge in branch1 to join branch2 as following command: branch1$ cvs -q update -Pd -kk -j branch1 -j branch2 There is only one file shown me the conflicts by and comments embedded in the file. Many other files in branch1 are simply replaced by branch2 source files and created .#file1.h.1.2.3, .#file2.c.1.2.5 For example, the file1.h in branch1 includes three functions A(), B() and C(). The file1.h in branch2 has only two functions A() and B(). I expected that the merged new file would include A(), B() and C(), but to be surprised, the new merged file has only A() and B(), same as branch2 source file. The function C() was simply lost. Is this normal behavior or am I missing something here? (CVS version 1.10 for Window, I guess, it is irrelevant) Thank you. yh __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ 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: Can't create a module in cvswin1.13
Do you have a log of what happened during the import, and during your attempt to check out? How are you setting your CVSROOT, in an environment variable, or on the command line? Are you using the command line cvs, or wincvs (etc)? [EMAIL PROTECTED] wrote on 11/11/2003 02:52:07 PM: Dear All: I wasn't able to create a module in my local repository. I followed the instruction verbatim! I am running from a local drive and once I imported an emty or populated directory, I can't check it out locally?? It keeps telling me the Module name can't be found? I ran the Admin command Get the cvs modules But cvs tells me theat No module entries found! Consult your repository's admin. What could have done wrong!! Thanks, __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ 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: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 04:37:03 PM: I see it now, and I thought that the conflicts you now say don't occur were the ones you objected to in the first place. Not at all. The conflicts that troubled me were happening because I was double-merging (when bringing B back to the trunk, merging from 1-4 instead of 2-4), _until_ I used the technique laid out in that email. The conflicts in question are what you describe, here: If A branched first, then 2-4 will attempt to remerge changes made to the trunk between the base of A and the base of B, causing the same sort of spurious conflicts you were attempting to avoid. And that did not seem to be true. It seemed to me that those changes are not merged twice - as I said, The changes between the start of A and the start of B are not in A, and they are inherent in B. So I am wondering if I tested it wrong and am thinking about it wrong? Regardless, some of what you said in that email was correct and some wasn't, but I don't think you can solve the general case without saving a merge history for each revision of each file. If individual files can't merge, and only whole branches can, I confess I don't understand why that is true, unless by saying the general case we are actually discussing something different than I imagine. One other thing I was wondering about was what I found when experimenting with the approach you suggest (using multiple merges): that conflicts arise during the interim steps, making the process unworkable. I am interested in single-step merges both because it _seems_ possible generally to construct one appropriate to a given case, and because they appear to me to avoid the issues of conflicts during interim merge steps. It isn't. The existing GCA algorithm is merely a convenience to avoid typing a start-revision in the most common case (merging from a branch to its parent) and I think it actually confuses more people than it Let me clarify what I mean a bit more. I want to generalize the process of finding a merge start point based on merge and branch information. I think the CVS GCA system is an interesting approach when working with branch information alone. If I understand it correctly, it is analogous to walking backwards up the ancestry of the source branch, searching for the most recent branch point on any common parent, of the souce or the destination branch (whichever is older). What I am experimenting with is the notion that if you add merge information to the mix, this approach still works. I am gathering that you don't think it will; but I guess what I am wondering, in that case, is, how will it fail? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 08:57:22 AM: The way to avoid only processing this for whole branch merges is to track individual commits as change sets. For example, store that the sum of changesets for file1 1.2 - 1.2.4.7 have been merged into the trunk. Then later, if a merge is attempted from 1.1 through 1.2.4.103.2.17, CVS could notice that the changesets above lay in the path and merge 1.1 - 1.2 1.2.4.7 - 1.2.4.103.2.17 as two separate merges. If 1.2.4.103.2.1 - 1.2.4.103.2.10 has already been merged as well, then that could be subtracted as well, leaving CVS with three merges: ~1.1 -1.2 ~1.2.4.7 - 1.2.4.103 ~1.2.4.103.2.10 - 1.2.4.103.2.17 and so on. I'm curious, do you think that multi-step merges will be required for the general case? Did you see my response to your original email? You had thought that multiple merges were necessary for that example, but when I studied it it didn't look that way. http://mail.gnu.org/archive/html/info-cvs/2003-11/msg00053.html Isn't it possible that, if I do whole branch merges, I can handle everything with single merge operations... subject to caveats: No, I don't think there is a general way to handle this. Or, at least the general way is to allow the user to pass a switch or somesuch to override the smart behavior so the merge can be reapplied. Note that this requires that CVS report when it skips portions of a requested merge so that the user will know this is necessary. Certainly that switch is assumed. But say for the sake of argument that it is all or nothing. In other words, if you want to use the smart merges, you have to follow the smart merge rules. That merely means doing some things a bit differently; for instance, if you want to use merge as a tool in more unconventional ways (I want to re-merge this branch because changes from it were accidentally deleted), you have to find other solutions. In the case of this example, I'd envision using the conventional merge operations to easily simulate undoing the mistake without additional complexity. |My cursory examination of CVS's GCA algorithm leaves me with the |impression that it relies on properties of the revision numbering system, |which if true makes it abundantly clear why there is no simple path to |making CVS smarter about GCA, even if it did have the information about |merge activity that it needed. No, this would not make CVS smarter about GCA. This would make CVS smarter about merging. Please do not misuse the term GCA this way. GCA has a well-defined meaning and well-established usage in CVS and the algorithm we are discussing has little to do with determining the ancestor, except possibly for determining an implicit start point for a merge request, which is exactly how the GCA is used currently. I will be careful not to confuse the term GCA with any new, more automated system for determining merge start points. I meant to draw the comparison only because what I envisioned for such a new system seemed functionally very similar to the existing CVS GCA algorithm (in function, of course, not in implementation). Or am I wrong even in this? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Please correct me if I'm wrong. I _think_ this is the greatest common ancestor problem. And finding one is actually something CVS does for you - on the first mege (with a single -j). Which is usually OK in cases where a branch immediately dies (i.e. becomes dormant) afterwards. The problem is that CVS does not remember that a merge took place. After a merge, the map of ancestry that was built by branch operations is no longer correct. And from that point on, CVS relies on _you_ to find the GCA. [EMAIL PROTECTED] wrote on 11/05/2003 03:55:38 AM: Is it just me, or is this getting way too complex to be usable except by CVS experts? I thought I was comfortable with the issues surrounding branches and merges, even though we are not using branches yet here. But I don't understand half of what you folks are saying. Worse: in my understanding this isn't even a particularly complex case. Let me see if I have this right. You want to merge changes made on a branch back into the main development stream, then merge that with the changes on another branch. Surely **everyone** will need to do this, sooner or later? Andy Jones. At 03:37 am 5/11/03, David Wood wrote: I am not sure about something. |If branch A and branch B in your example don't branch form the same |point on the trunk, a merge from point 2 to point 4 into the trunk might |still not do what you want. If branch B branched first, then 2-4 may |back out changes made to the trunk between the base of B and the base of |A. If A branched first, then 2-4 will attempt to remerge changes made |to the trunk between the base of A and the base of B, causing the same |sort of spurious conflicts you were attempting to avoid. Assume B is branched first. A merges to the trunk. Then A merges to B. Then B merges to the trunk as well. I think the trick here is what happens when A merges to B. If you do that merge like this: (in B's working dir): cvs update -j branchA_CREATED -j 3 (3 == where A merges to B) then you are correct. This merge will be missing changes from between the start of B and A - ALREADY! In other words, with respect to B, part of A was left out, since it was created before branchA_CREATED - on the trunk. But I think this is really the wrong way to merge A into B. The right way is to do it would be to say: cvs update -j branchB_CREATED -j 3 Then branch B does indeed end up incorporating everything from branch A. In other words, the changes on the trunk after B was created until A starts, and then all then all the changes in A. So when doing that kind of merge, always use the newest common ancestor (in this case, the start of B). Now let's look at your other scenario. When A is created before B, everything else being equal, I did not receive spurious conflicts doing that last merge in a single step (2-4, Jamie's way) after all! You say there should be, because that I am remerging changes made to the trunk between the base of A and the base of B. But I can't see where the redundancy should come from. The changes between the start of A and the start of B are not in A, and they are inherent in B. So goes my theory. Perhaps we are making different assumptions? |The only clean way to do this in the general case is to tag branch B |before and after your merge from A at point 3 and merge B back into the |trunk as two merges: | |~cvs up -j 1 -j pre-3 |~cvs up -j post-3 -j 4 ... Oops, yes, you are correct. What I said was correct if point 2 3 were the same (at point 2 all of branch A was merge to both the trunk and branch B). A clean merge to the trunk without conflicts from a repeated merge with distinct points 2 3 would require the two commands I listed above and a third merge: ~cvs up -j 2 -j 3 So if I understand you all correctly, a generalized merge formula would be: cvs update -j start-of-branchB -j pre-3' cvs update -j 2 -j 3 cvs update -j post-3' -j 4 in that order? What if branchB had made changes that would conflict with branchA's changes, and the merge from A to B is to correct that conflict and bring B into sync _before_ it merges with the trunk? Following this pattern, I will still get that conflict between B and the trunk on the first command - even though those conflicts had already been resolved post-3'. Nothing subsequent would work without manually duplicating the conflict resolution already present in B... ___ 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
Re: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM: No. The GCA has not changed and CVS determines it correctly. You simply no longer wish to merge from the GCA forward because some of those changes were already merged to your destination (from another branch and at your own request - CVS did nothing wrong) and you wish to avoid conflicts. I am not saying CVS is doing anything wrong; I think it is following its design precisely. I think my problem may be with terminology. If I merge from a child to the trunk, and then I later merge it again, what is the greatest common ancestor on that second merge? Still the beginning of the child? Or is it now point of the first merge? It sounds like you are saying the former - following the strict CVS definition for GCA, that is right. But what about an alternate definition of ancestry based on both branches _and_ merges? Right now to do that second merge I have to tell CVS where to start - it no longer uses its GCA algorithm to figure that out for me. But I am telling it the new common ancestor myself - the point of the previous merge (as opposed to the point of the branch). Isn't this an analogous process to CVS' current GCA? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 12:43:14 PM: Greatest Common Ancestor, or GCA, is a term that refers to the RCS revision structure and always means the more recent revision two revisions have in common, often a branch point, but in the case of a branch of a branch and the trunk, note that the GCA is on the trunk, not the base revision of the branch, but the base revision of its parent. So in other words, you are saying: in the case where the branch (child) of a branch (parent) merges back to the trunk (grandparent), the GCA is on the grandparent, at the point where the parent begins. Right? CVS determines GCA when you only specify one revision in a merge as a convenience for the common case, merging from a branch into its parent. This does not mean that the first revision of a merge specification should always be called a GCA. Yes, it would be convenient if CVS were smart enough to track what data has already been merged to various locations and attempt to intellegently exclude these data sets in following merges. This has been suggested many times in the past. In practice, CVS does not currently keep track of the necessary data and even if it did, the problem is a very hard one. There _are_ reasons a user could wish to specify a merge twice. They accidentally copied old files over the new ones which had contained the merge; another developer removed the merge changes by hand and committed in conjunction with code you do not want removed. etc.Basically, CVS would have a hard time tracking what you manually did to its merge result. If someone were to solve this problem and submit a patch that implemented the solution including documentation and tests cases which addressed these sorts of issues and any others that arose, believe me, I would be one of the first to vote that CVS incorporate the code. I am hopeful that someone will be me. My initial approach has been to use a wrapper which executes branches and merges, generating and applying tags in addition to branching and merging, and maintaining extra state data in a database. I believe that the tool has all of the necessary information available; the question now is using it to determine the correct merge start point in a general way. I only intend to support whole branch merges, and I have been under the impression that I can focus solely on eliminating over- and under-merging. I believe cases such as your examples, where it is desirable to double merge, or to deliberately eliminate part of the merge, cannot be handled in a general way - although perhaps you will disagree? My cursory examination of CVS's GCA algorithm leaves me with the impression that it relies on properties of the revision numbering system, which if true makes it abundantly clear why there is no simple path to making CVS smarter about GCA, even if it did have the information about merge activity that it needed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Rephrasing: question about merging branches
Let me try to put it another way. I have a parent branch, and it has two child branches. If I want one child to merge to the parent, and then to the other child, how does that other child later merge to the parent as well? Is it (on the parent): update -j first_child_merge_point -j second child If so, what happens to changes from before the first_child_merge_point? -David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
I would say your ascii graphic is admirable! What you are saying matches what I'm seeing in tests, and I think I get it now. I believe my problem has been a silly confusion with the way update -j -j works. I understand a merge between 1 and 4 (and for that matter, a reverse-merge between 4 and 1) well enough. Essentially, I mistakenly envisioned a merge between 3' and 4 - rather than 2 and 4. Hence my fear about loss or mistreatment of changes before the child-to-child merge. I think what all this means is that branchB is now essentially merging against branchA (having received common chagnes by, and resolved conflicts with) branchA... and the merge delta with the trunk must now use branchA (at point 2) as a reference point in order to correctly reflect changes against the trunk. It is potentially confusing, but you have made it seem very simple. Thank you! -David Jamie Wellnitz [EMAIL PROTECTED] wrote on 11/04/2003 11:50:35 AM: Sorry for the ascii graphic in advance . . . If you have (* indicates merge point): branchA and branchB originated from trunk at point 1. branchA merged to trunk at point 2 on branchA and 2' on trunk. branchA then merged to branchB at point 3 on branchA and 3' on branchB. Now, we want to merge branchB (point 4) to the trunk (4'). branchA 23 /-\-\ 1 / \ \ 4' trunk --* \ -* \2' \/ \---*--/-- branchB 3' 4 I think you want the common ancestor of the current branchB tip and trunk tip. That would be point2 on branchA. (This is assuming you did a full merges, not just a few changes, from A-trunk and A-B.) So assuming you put tags down to keep track of the merge points, you might try (on the trunk): cvs update -j point2 -j point4 It looks like my point2 is your first child merge point and second child is the tip of branchB (where you put a tag before the merge). Which changes before the first child merge point are you wondering about? Thanks, Jamie Wellnitz [EMAIL PROTECTED] On Tue, Nov 04, 2003 at 11:06:44AM -0500, David Wood wrote: Let me try to put it another way. I have a parent branch, and it has two child branches. If I want one child to merge to the parent, and then to the other child, how does that other child later merge to the parent as well? Is it (on the parent): update -j first_child_merge_point -j second child If so, what happens to changes from before the first_child_merge_point? -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: Rephrasing: question about merging branches
I am not sure about something. |If branch A and branch B in your example don't branch form the same |point on the trunk, a merge from point 2 to point 4 into the trunk might |still not do what you want. If branch B branched first, then 2-4 may |back out changes made to the trunk between the base of B and the base of |A. If A branched first, then 2-4 will attempt to remerge changes made |to the trunk between the base of A and the base of B, causing the same |sort of spurious conflicts you were attempting to avoid. Assume B is branched first. A merges to the trunk. Then A merges to B. Then B merges to the trunk as well. I think the trick here is what happens when A merges to B. If you do that merge like this: (in B's working dir): cvs update -j branchA_CREATED -j 3 (3 == where A merges to B) then you are correct. This merge will be missing changes from between the start of B and A - ALREADY! In other words, with respect to B, part of A was left out, since it was created before branchA_CREATED - on the trunk. But I think this is really the wrong way to merge A into B. The right way is to do it would be to say: cvs update -j branchB_CREATED -j 3 Then branch B does indeed end up incorporating everything from branch A. In other words, the changes on the trunk after B was created until A starts, and then all then all the changes in A. So when doing that kind of merge, always use the newest common ancestor (in this case, the start of B). Now let's look at your other scenario. When A is created before B, everything else being equal, I did not receive spurious conflicts doing that last merge in a single step (2-4, Jamie's way) after all! You say there should be, because that I am remerging changes made to the trunk between the base of A and the base of B. But I can't see where the redundancy should come from. The changes between the start of A and the start of B are not in A, and they are inherent in B. So goes my theory. Perhaps we are making different assumptions? |The only clean way to do this in the general case is to tag branch B |before and after your merge from A at point 3 and merge B back into the |trunk as two merges: | |~cvs up -j 1 -j pre-3 |~cvs up -j post-3 -j 4 ... Oops, yes, you are correct. What I said was correct if point 2 3 were the same (at point 2 all of branch A was merge to both the trunk and branch B). A clean merge to the trunk without conflicts from a repeated merge with distinct points 2 3 would require the two commands I listed above and a third merge: ~cvs up -j 2 -j 3 So if I understand you all correctly, a generalized merge formula would be: cvs update -j start-of-branchB -j pre-3' cvs update -j 2 -j 3 cvs update -j post-3' -j 4 in that order? What if branchB had made changes that would conflict with branchA's changes, and the merge from A to B is to correct that conflict and bring B into sync _before_ it merges with the trunk? Following this pattern, I will still get that conflict between B and the trunk on the first command - even though those conflicts had already been resolved post-3'. Nothing subsequent would work without manually duplicating the conflict resolution already present in B... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Conflict committed
I just found that one of the developers here has managed to commit a file with a conflict in it. I had been under the impression, based on documentation and past experience, that it was impossible to commit a file with conflict markers inside it. However, I just witnessed this. Are my assumptions about this mistaken? What circumstances allow unresolved conflicts to be committed back to the repository? -David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Conflict committed
Thank you for the advice about commitinfo. I believe we will do exactly that as a safeguard against future problems. I totally respect that CVS should be content agnostic, although I did have to rename my cvs java package to cvsutil because you can't have dirs named cvs in the repository... It's too bad such a safeguard can't be offered as a kind of optional-but-default condition. Common case, etc. [EMAIL PROTECTED] wrote on 10/29/2003 12:07:28 PM: The timestamp of the file being changed will let the file with conflicts be committed with just a warning. Some folks consider it useful to check for conflict markers in their commitinfo scripts and refuse the commit. It is not up to cvs to determine what data patterns should or should not be allowed to be committed into a file. -- Mark Example: % cd /tmp % mkdir testit % cd testit % cvs -d /tmp/testit/cvs-testrepos init % cvs -d /tmp/testit/cvs-testrepos co CVSROOT % cd CVSROOT/ % (echo aaa; echo bbb; echo ccc) file1 % cvs add file1 % cvs ci -mnew file1 % echo ddd file1 % cvs ci -madd file1 % echo eee file1 % cvs up -j1.2 -j1.1 file1 % cat file1 aaa bbb ccc file1 ddd eee === 1.1 % touch file1 % cvs ci -mconflict file1 cvs commit: warning: file `file1' seems to still contain conflict indicators Checking in file1; /tmp/cvs-testrepos/CVSROOT/file1,v -- file1 new revision: 1.3; previous revision: 1.2 done cvs commit: Rebuilding administrative file database % -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/n/PQ3x41pRYZE/gRAqT1AKDVi92UQJZorCK47WNQcrSBtFPWOACg3T1T b6nolaHXENd1+/R0jqRIxZY= =k4nC -END PGP SIGNATURE- ___ 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
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 development with CVS. There have already been questions (and answers) like this in the mailing list. I don't know the topic anymore but if you browse the archive you may find some good descriptions, sometimes with links to more info. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Stale lock files with anonymous CVS
We have a CVS repository here where some users have read only access except in a few directories, and the rest have read-write access everywhere. This does work as advertised, except that when a read-only user attempts to put a file where they shouldn't, we end up with a stale lock. Then no one can use the repository until it's manually removed. It seems that when the CVS process on our (Solaris 9) server has a permission problem, it dies without removing its lock files. FYI, we are using a seperate lock directory. When CVS dies it gives the error: cvs commit: ERROR: cannot write file /opt/cvs/repositories/primary/myproject/test/Attic/testfile2.html,v: Permission denied Terminated with fatal signal 11 The read-write users map to user CVS. Read-only users map to user CVSR. Both belong to group CVS Most files are rwx for user CVS, and r-x for group CVS. Directories where read-only users can write are rwx for user CVSR, and rwx for group CVS. I haven't found any information about this kind of problem over several days of searching. Given that the very popular anonymous CVS repositories around the world must use a similar technique, and such a condition would make them notoriously abusable (i.e. trivial, evil DOS attack), I assume I must be doing something wrong. Does anyone have any ideas? Thanks, -David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
