Re: Import and merge into branch
[ On Sunday, October 31, 2004 at 20:59:56 (-0800), Mark D. Baushke wrote: ] Subject: Re: Import and merge into branch There is no risk of cvs getting confused by creating a new branch from a version tag of any kind. That's not exactly true in all cases. ;-) CVS will get confused if a new normal branch is created (i.e. with cvs tag) in a module created with cvs import and then another subsequent import is done and an attempt is made to merge it. CVS vendor branches do not co-exist well with normal CVS branches due to the optimizations used and due to the hackish default branch magic used for vendor branches. As you know the mechanics are rather complex to work through but suffice it to say that newly imported changes can suddenly appear in the wrong places when vendor branches and normal branches are mixed. I see this too regularly in the NetBSD repository where I do all my local work in a directory that was checked out from a normal branch and where sometimes cvs import is used imporoperly to update third-party code and where local changes are also made on the trunk of that third party code. Of course as you suggest below it is also true that even just with the normal vendor branch management tactics, i.e. even when no normal branches exist, that the whole module in the repository is in an inconsistent state between the time the import is started and the time the commit of the merge of new vendor changes to the trunk of locally changed files is completed. Future direction change: The cvs 1.12.10 (not yet released) will have a -X option to import that allows you to import and not be visible on the main trunk by default. Version 1.1 exists (it always needs to be created) and version 1.1.1.1 is the first imported version, then with -X a dead 1.2 version is created right away. This protects the main trunk from imports that might confuse it and allows you to merge vendor files into the main trunk in a controlled commit in conjunction with other mainline files. I don't think that's really going to help much in the case where normal changes also exist, but I've not thought it through entirely. I.e. I think one would also have to get rid of the reliance of the default branch hack in vendor branched modules in order to make it work as safely as possible. I.e. the right thing to do would be to completely eliminate the stupid 1.1.1 branch junk and to always create and treat the vendor branch as a normal branch and to always do a full commit of new vendor releases to that branch and then to a normal, manual, merge of the changes on the vendor's branch to the, or to each, local branch as necessary. Such a change would of course be incompatible with existing repositories containing the current style vendor-branched modules. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import and merge into branch
OK, thanks a lot for your reply, but wouldn't this create the branch from the magic import branch? Is that really ok? Is there no danger in creating branches from the revisions in a magic branch? Best Regards / Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: den 29 oktober 2004 18:15 To: Erik Andersson Cc: [EMAIL PROTECTED] Subject: Re: Import and merge into branch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Assuming you did cvs import module VENDOR VENDOR-VERSION then something like this: cvs rtag -b -r VENDOR-VERSION newbranch module cvs checkout -r newbranch module should get what you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBgmyh3x41pRYZE/gRAnpJAKCe/kOFLGyMGQlFiiKH7rpNNFlSawCdEO54 Y37ySHXbJrOLgcioz92Csqw= =+vFW -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import and merge into branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: OK, thanks a lot for your reply, but wouldn't this create the branch from the magic import branch? If you mean that newbranch will have a magic version number of something like 1.1.1.1.0.2 and commits to it will look like 1.1.1.1.2.1, then yes. Is that really ok? Sure, I do it all the time. Is there no danger in creating branches from the revisions in a magic branch? The vendor branch is not a magic branch (unless you did something very odd when you did the import with the -b option?), it is branch 1.1.1 and you would be maging a 'magic branch' from the latest VENDOR-VERSION tag which is not itself a branch. -- Mark Best Regards / Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: den 29 oktober 2004 18:15 To: Erik Andersson Cc: [EMAIL PROTECTED] Subject: Re: Import and merge into branch Erik Andersson [EMAIL PROTECTED] writes: I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Assuming you did cvs import module VENDOR VENDOR-VERSION then something like this: cvs rtag -b -r VENDOR-VERSION newbranch module cvs checkout -r newbranch module should get what you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBhQkF3x41pRYZE/gRAu/sAKDMgISDuYEyiS2LPO91cSXTJOYz2QCfd8hf C4y19fASes/ETRtLxqVllq8= =jDtA -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import and merge into branch
Thanks a lot again!! So it's really now risk in creating the branches directly from the release version tags? Someone told me that this would be a risk for CVS to get confused. We have already spent to much time trying to fix this so I really need to get this things straighten out before I go talk to my boss.. I would also appreciate other peoples say, although I think I really should trust Mark ;-) What we really wanted to do was to go from another versioning system to CVS and and for this we used the import. We have a lot of projects working across eachother and often working with the same files etc. This is what's was sent to me and this is from what I am to understand that this is the way for us to go: CVS Guidelines. These guidelines are written on current experience with larges projects having many parallel branches of the same source in various states. Projects not having so much going on in parallel can get much easier off than what these guidelines states. Converting from another project If conversion from another versioning system is needed before using CVS, then care should be taken if conversion must maintain existing current development and/or multiple stages/milestones from the old versioning system. CVS has a sort of odd way of using revision numbers when importing. First revision is 1.1.1.1 and Not 1.1. However, when modifying a file in main trunk the first change on that file will get revision 1.2! This is quite important to notice as it is needed when changing to use CVS from another versioning system at a time where active branches still exists. The following images/filesets are absolutely necessary when changing to CVS and not loosing active states. The assumption is that all branches are decendents of main trunk and that they are in parallel. Each branching point for creating each branch must be extracted. Each branch must be extracted in latest'n'greatest state - ie. head of each branch. All branching point must be known date-wise to import into CVS in correct order.. Head of main trunk must be extracted. A state previous to the earliest branching point must be extracted from main trunk. It is important to beware of the fact that the last import dictates how main trunk looks in the final state. When importing it is Vital to use the same vendor tag and a new release tag for every new import. To make the import behave correctly and to get the desired result, the following way of building the repository could be used: Import what is going to be head of main trunk. Import each branching point in reverse date order. Import each branch-head. Import the comming ancestor (the oldest main trunk state). Force commit of main trunkt to set all revisions to 1.2. Merge differences from imports to main trunk to create each branching point in main trunk. Remeber to set a tag after each merge for indentification. Branch of each branching point, checkout each branch and make a recursive force commit. This gives revisions like 1.X.2.1 for all files, where X is the version from main trunk. For each branch merge differences from import to create head of branch. For main trunk merge the last for setting the real head state. It is a lot of imports and merges, but you should end up with something like: Main +---Import Head-of-main (1) || | Import Branching-point-2 (2) | Import Branching-point-1 (3) | Import Branch-head-1 (4) | Import Branch-head-2 (5) || | Import Ancestor (6) | (A) -- forced commit giving state of (6) | (B) -- merge to branching-point-1 (-j ancestor -j branching-point-1) | \ | \ Branching to branch-1 | | | Forced commit + set start tag | | | Branch-1 head -- Merge to branch-2 head (-j branching-point-1 -j branch-head-1) | | (C) -- merge to branching-point-2 (-j branching-point-1 -j branching-point-2) | \ | \ Branching to branch-2 | | | Forced commit + set start tag | | | Branch-2 head -- Merge to branch-2 head (-j branching-point-2 -j branch-head-2) | | (D) -- merge to Head-of-main (-j branching-point-2 -j head-of-main) The resulting state (D) should be the production state. If this setup should be carried out to create the branches according to the branching strategy below, then a little further branching and forced commits are necessary, but it is not especially complicated. Branching strategy Branches should normally reference the current state of a given environment. In this context with larger projects it gives: production | +---Test | +---Development This mostly when a lot of developers are involved. Having a full environment with the above structure, then it becomes almost vital
Re: Import and merge into branch
, the following way of building the repository could be used: Import what is going to be head of main trunk. Good idea. Import each branching point in reverse date order. Reasonable. Import each branch-head. Hmmm... possibly, depending on what is meant by this. Import the comming ancestor (the oldest main trunk state). Yup. Force commit of main trunkt to set all revisions to 1.2. See use of the -X option above... Merge differences from imports to main trunk to create each branching point in main trunk. Remeber to set a tag after each merge for indentification. Yup. Branch of each branching point, checkout each branch and make a recursive force commit. This gives revisions like 1.X.2.1 for all files, where X is the version from main trunk. I am not sure this is necessarily reasonable or correct or desirable. For each branch merge differences from import to create head of branch. For main trunk merge the last for setting the real head state. It is a lot of imports and merges, but you should end up with something like: Main +---Import Head-of-main (1) || | Import Branching-point-2 (2) | Import Branching-point-1 (3) | Import Branch-head-1 (4) | Import Branch-head-2 (5) || | Import Ancestor (6) | (A) -- forced commit giving state of (6) | (B) -- merge to branching-point-1 (-j ancestor -j branching-point-1) | \ | \ Branching to branch-1 | | | Forced commit + set start tag | | | Branch-1 head -- Merge to branch-2 head (-j branching-point-1 -j branch-head-1) | | (C) -- merge to branching-point-2 (-j branching-point-1 -j branching-point-2) | \ | \ Branching to branch-2 | | | Forced commit + set start tag | | | Branch-2 head -- Merge to branch-2 head (-j branching-point-2 -j branch-head-2) | | (D) -- merge to Head-of-main (-j branching-point-2 -j head-of-main) The resulting state (D) should be the production state. If this setup should be carried out to create the branches according to the branching strategy below, then a little further branching and forced commits are necessary, but it is not especially complicated. Branching strategy Branches should normally reference the current state of a given environment. In this context with larger projects it gives: production | +---Test | +---Development This mostly when a lot of developers are involved. Having a full environment with the above structure, then it becomes almost vital that CVS is used correctly and that CVS is somewhat prohibited from making errors when merging. This can be done by forcing a commit on ALL files whenever creating a new branch. Production will always be carried in the main trunk of CVS and everything else will be branched out from there. Taking the above into consideration, then when making a development branch, which must be applied to Test before it goes to production, then when making the Test branch, all files must be forced committed to make the revisions correct before making the development branch. The issue here is if this is not done, then the development branch will be a parallel branch to the Test branch, which is not what you want. The reason is that CVS does not assign a new revision to a file when creating a branch - it either needs a change or a forced commit. As most environments also need bugfixing, then a branch for that would usually come in very handy. My resulting branching structure thus becomes to be like this: Production | +---prod-bugfix | +---Test | +---test-bugfix || |+---patchXX |+--- | +---Development-shared | +---ProjectA +---ProjectB +--- Notes: The normal bugfix branch would be test-bugfix as prod-bugfix is only to be used for emergencies. The patchXX branches could be simulated using pre/post tags in the test-bugfix branch, which gives the endpoints for merges. Best Regards / Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBhcLM3x41pRYZE/gRAvwoAKCp8SMaPNr34Uy86zPHX5AUjxAhowCg17da pQeak59XvMhsY2XWyhwHP3I= =Js6v -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Import and merge into branch
Hi I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Best Regards / Erik CIP Development Environments, [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import and merge into branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Assuming you did cvs import module VENDOR VENDOR-VERSION then something like this: cvs rtag -b -r VENDOR-VERSION newbranch module cvs checkout -r newbranch module should get what you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBgmyh3x41pRYZE/gRAnpJAKCe/kOFLGyMGQlFiiKH7rpNNFlSawCdEO54 Y37ySHXbJrOLgcioz92Csqw= =+vFW -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Merge to branch
Hello, I have a main trunk and a branch R18. Some changes (on 3 files) have been made by programmer on the main trunk but they should have been done in the R18 branch. I'd like the changes made on the three files to be merged (or just copied) to the R18 branch. Of course, the R18 branch should continue to live but with the changes (I hope my english is good enougth...). Thanks. Jean ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge to branch
If both main trunk and branch R18 are in sync till now, then you can merge the changes with following with branch as working copy. cvs update -j HEAD -j R18 your file names This also assumes that there are no commits to main trunk after your required changes. otherwise they will also be merged into the branch. HTH Rohan news wrote: Hello, I have a main trunk and a branch R18. Some changes (on 3 files) have been made by programmer on the main trunk but they should have been done in the R18 branch. I'd like the changes made on the three files to be merged (or just copied) to the R18 branch. Of course, the R18 branch should continue to live but with the changes (I hope my english is good enougth...). Thanks. Jean ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge to branch
news wrote: I have a main trunk and a branch R18. Some changes (on 3 files) have been made by programmer on the main trunk but they should have been done in the R18 branch. I'd like the changes made on the three files to be merged (or just copied) to the R18 branch. Of course, the R18 branch should continue to live but with the changes (I hope my english is good enougth...). First of all, your english was more than sufficient to communicate your problem. Fixing this will be quite simple. For simplicity, I will assume that there exist tags 'original' and 'incorrect', which refer to the trunk revisions immediately prior to the check in, and immediately after the check in. For example, if the developer had revision 1.2 checked out, modified it, and checked it in to become rev 1.3 then 'original' would be 1.2, and 'incorrect' would be 1.3. Since there are only three files involved, you could probably simply use the numeric revision instead of applying tags. On the trunk: cvs up -j incorrect -j original file1 file2 file3 #fix up any conflicts# cvs di file1 file2 file3 #examine the diff to ensure it looks reasonable# cvs ci -m Backing out changes incorrectly checked into the trunk file1 file2 file3 On the branch: cvs update -r R18 cvs up -j original -j incorrect file1 file2 file3 #fix up any conflicts# cvs di file1 file2 file3 #examine the diff to ensure it looks reasonable# cvs ci file1 file2 file3 Note that the order of the -j parameters is different between the two commands. The first one does a negative delta to back out the changes on the trunk. The second one does a positive delta to apply the changes to the branch. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge to branch
Hello, Rohan Nandode [EMAIL PROTECTED] a écrit dans le message de news:[EMAIL PROTECTED] If both main trunk and branch R18 are in sync till now, then you can merge the changes with following with branch as working copy. cvs update -j HEAD -j R18 your file names Thank you very much. It was the main trunk name (HEAD) I didn't know ! It worked. Jean ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge to branch
Hello, Jim.Hyslop [EMAIL PROTECTED] a écrit dans le message de news:[EMAIL PROTECTED] Fixing this will be quite simple. For simplicity, I will assume that there ... Thank you very much for this method. I didn't know it was possible to merge 2 versions in the same branch. I have to read some docs to be more familiar with cvs (wincvs don't help, the help is a shame). Cordialement. Jean ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
merge a branch
HI guys: Is anybody had experimented merge a branch with different versions of cvs, cvs server 1.10 and cvs client 1.11, I need to merge a branch but I'm concern about that I have different version of cvs, is there a wholesome and safety to do this. if we have a problem and I put a tag name before I merge is enough to return to original branch?? please advised. Thanks Moises. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Merge of branch to trunk fails (cvs server: no such file)
[lmartel@scheme mpeg]$ cvs -n update -l -jPrediction-Branch ? DebugFiles cvs server: Updating . U API.h U APISim.cpp RCS file: /opt/cvsroot/mpeg/ClearBorder.cpp,v retrieving revision 1.2 retrieving revision 1.2.2.1 Merging differences between 1.2 and 1.2.2.1 into ClearBorder.cpp cvs server: ClearBorder.cpp: No such file or directory U API_ID.h -- Here is the command and the result we get. Although commands like update/commit etc work on the trunk and the branch successfully, this does not work. 2) Shouldn't -l limit the operation to the local directory. The API related files that you are kept in a subdirectory. Why are they included in the operation? Arcin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge or branch?
From: Christine Freight ([EMAIL PROTECTED]) I am having a dispute with a co-worker over how to do something in CVS. I was wondering if anyone out there can help? Here's the situation: A branch (let's call it branchA) gets created off the main line. Then, at some point in time, a branch (branchB) gets created off of branchA. Development continues down branchA, and a new directory, with new files, gets added and committed on branchA. This new directory is obviously not on branchB, since it was created after branchA was created. Question: how does one get the new directory from branchA onto branchB? I would merge the branchA changes into branchB cvs co -r branchB everything cd everything cvs update -d -j branchB_origin -j branchA new_directory cvs commit -m 'merged new_directory from branchA' You did create a tag (branchB_origin, above) to mark the beginning of branchB, right? Also, partial merges like this, (mergiing in _just_ the new_directory) instead of the whole branch, can make it difficult to keep track of what's merged and what's not later on, so be careful and use tags liberally to keep things straight.. So you'd probably want to tag branchA to indicate which portion was merged into branchB. Something like: cvs rtag -r branchB_origin branchA_merged_to_branchB everything cvs rtag -F -r branchA branchA_merged_to_branchB new_directory so that future merges from A to B could use this tag as a starting point and not have re-merge the same changes again. -- steve __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge or branch?
Thanks Steve. Yep, I created a branch origin tag, so I know where the branch forked off. I appreciate the help! ~Christine Stephen Cameron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... From: Christine Freight ([EMAIL PROTECTED]) I am having a dispute with a co-worker over how to do something in CVS. I was wondering if anyone out there can help? Here's the situation: A branch (let's call it branchA) gets created off the main line. Then, at some point in time, a branch (branchB) gets created off of branchA. Development continues down branchA, and a new directory, with new files, gets added and committed on branchA. This new directory is obviously not on branchB, since it was created after branchA was created. Question: how does one get the new directory from branchA onto branchB? I would merge the branchA changes into branchB cvs co -r branchB everything cd everything cvs update -d -j branchB_origin -j branchA new_directory cvs commit -m 'merged new_directory from branchA' You did create a tag (branchB_origin, above) to mark the beginning of branchB, right? Also, partial merges like this, (mergiing in _just_ the new_directory) instead of the whole branch, can make it difficult to keep track of what's merged and what's not later on, so be careful and use tags liberally to keep things straight.. So you'd probably want to tag branchA to indicate which portion was merged into branchB. Something like: cvs rtag -r branchB_origin branchA_merged_to_branchB everything cvs rtag -F -r branchA branchA_merged_to_branchB new_directory so that future merges from A to B could use this tag as a starting point and not have re-merge the same changes again. -- steve __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
merge or branch?
Hey Folks~ I am having a dispute with a co-worker over how to do something in CVS. I was wondering if anyone out there can help? Here's the situation: A branch (let's call it branchA) gets created off the main line. Then, at some point in time, a branch (branchB) gets created off of branchA. Development continues down branchA, and a new directory, with new files, gets added and committed on branchA. This new directory is obviously not on branchB, since it was created after branchA was created. Question: how does one get the new directory from branchA onto branchB? We have two answers: 1. merge the directory from branchA to branchB. I had a little trouble coming up with the command to do this (I am new to CVS), but that was the obvious answer to me. (in a branchA sandbox, do a cvs update -j branchB filename, or dirname) 2. branch the new files in the new directory using the branchB branch tag. In other words: cvs tag -b branchB newfilename. My thoughts are option #2 will create another branch, with the same name (branchB) in cvs. I believe that option 2 will give my colleague what he wants, but I still believe two separate branches were created and merging would have been the better way to go as it would have brought the files over to the original branchB branch. Any opinions? Thanks so much! ~Christine ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge or branch?
At 23:42 27/09/2001 +, you wrote: Development continues down branchA, and a new directory, with new files, gets added and committed on branchA. This new directory is obviously not on branchB, since it was created after branchA was created. I would suggest that you perform the new additions from the mainline (HEAD) whenever you add new directory and files. To get these files down the branch, you'll need to 'branch' these additions. Why? Well, firstly, files added in the branch would be stored in the Attic directory. Secondly, I experienced some problems in merging these type of files back to the HEAD branch. Question: how does one get the new directory from branchA onto branchB? 2. branch the new files in the new directory using the branchB branch tag. In other words: cvs tag -b branchB newfilename. My thoughts are option #2 will create another branch, with the same name (branchB) in cvs. I believe that option 2 will give my colleague what he wants, but I still believe two separate branches were created and merging would have been the better way to go as it would have brought the files over to the original branchB branch. I prefer your option #2. I think CVS does not differentiate between the two 'branch'. Your colleague will simply need to update his local work directory: cvs update -r branchB Rachman _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
merge a branch which contains a name-changed file
Hi, On a specifie branch, I change a file's name from "old" to "new" (the file content is also changed). Next I am going to merge the branch into the HEAD. I hope to see the file "old" is replaced with "new" in the HEAD after the merge. Can I see it? ( I guess the case is: both files exist, and I have to remove the file "old" from HEAD) Thank you -S. Chen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge a branch which contains a name-changed file
Susie writes: On a specifie branch, I change a file's name from "old" to "new" (the file content is also changed). Next I am going to merge the branch into the HEAD. I hope to see the file "old" is replaced with "new" in the HEAD after the merge. Can I see it? ( I guess the case is: both files exist, and I have to remove the file "old" from HEAD) Assuming you did the rename by removing the old name and adding the new name and then committing those changes, the merge should try to remove the old name and add the new name. (But removing the old name will fail if there were changes on the trunk after the branchpoint which you will have to merge into the new file manually.) -Larry Jones I'm a genius. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge a branch which contains a name-changed file
One more thing. I have another branch B which is forked off the HEAD before the merge (i.e. B still contains the file with old name). If the merge removes old name and add the new name, what will happen to the file when I merge B into HEAD? Your help is very valuable to me : -Susie - Original Message - From: "Larry Jones" [EMAIL PROTECTED] To: "Susie" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 10:21 AM Subject: Re: merge a branch which contains a name-changed file Susie writes: On a specifie branch, I change a file's name from "old" to "new" (the file content is also changed). Next I am going to merge the branch into the HEAD. I hope to see the file "old" is replaced with "new" in the HEAD after the merge. Can I see it? ( I guess the case is: both files exist, and I have to remove the file "old" from HEAD) Assuming you did the rename by removing the old name and adding the new name and then committing those changes, the merge should try to remove the old name and add the new name. (But removing the old name will fail if there were changes on the trunk after the branchpoint which you will have to merge into the new file manually.) -Larry Jones I'm a genius. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
