Re: Howto solve this in cvs ?
On Thu, 11 Oct 2001, Greg A. Woods wrote: [ On Monday, October 1, 2001 at 09:12:24 (+), Gerhard Ahuis wrote: ] Subject: Re: Howto solve this in cvs ? Greg A. Woods [EMAIL PROTECTED] wrote: For many of the same reasons it's literally impossible to ever have true multi-vendor support too -- all the benefits of cvs import are completely impossible to achieve with multiple vendor branches. You can do multi-vendor tracking manually, but it's one hell of a lot more work (more work even than managing several variant branches in a locally initiated project)! There are not many files, so if you can give me some hints to let a second vendor branch showup on a normal cvs branch and not on the main, I will be very thankfull. Well, it's really quite straight forward. You simply have to create normal branches for each vendor, and corresponding working directories for each, and then manually commit and tag each new release on each release. It is already done now with 2 vendor branches.. Moving the branch tag to the corresponding vendor version does the job.. I tested commiting of files on the two branches and it all seems to work fine.. Cheers, Gerhard. -- Gerhard Ahuis [EMAIL PROTECTED] Unsolicited advertisements subject to $1000 consulting fee. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Howto solve this in cvs ?
[ On Friday, October 12, 2001 at 10:35:16 (+0200), Gerhard Ahuis wrote: ] Subject: Re: Howto solve this in cvs ? It is already done now with 2 vendor branches.. Moving the branch tag to the corresponding vendor version does the job.. I tested commiting of files on the two branches and it all seems to work fine.. You will encounter problems with multiple vendor branches, not the least of which is that you no longer have correctly working conflict detection on cvs import. I thought you also wanted to create normal branches from your local trunk version too. That won't work (well) with even one vendor branch. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Howto solve this in cvs ?
[ On Monday, October 1, 2001 at 09:12:24 (+), Gerhard Ahuis wrote: ] Subject: Re: Howto solve this in cvs ? Greg A. Woods [EMAIL PROTECTED] wrote: For many of the same reasons it's literally impossible to ever have true multi-vendor support too -- all the benefits of cvs import are completely impossible to achieve with multiple vendor branches. You can do multi-vendor tracking manually, but it's one hell of a lot more work (more work even than managing several variant branches in a locally initiated project)! There are not many files, so if you can give me some hints to let a second vendor branch showup on a normal cvs branch and not on the main, I will be very thankfull. Well, it's really quite straight forward. You simply have to create normal branches for each vendor, and corresponding working directories for each, and then manually commit and tag each new release on each release. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Howto solve this in cvs ?
Greg A. Woods [EMAIL PROTECTED] wrote: What is not working well ? I didn't have any problem until this problem arrises. Does it really matter when the problem raises its ugly head? Don't try to use normal branches with vendor branched modules unless you want to invite trouble! (This is unrelated to the following issue too!) It's really not that hard to figure out where the problems arise if you look in detail at how CVS creates branches and how cvs import works. For many of the same reasons it's literally impossible to ever have true multi-vendor support too -- all the benefits of cvs import are completely impossible to achieve with multiple vendor branches. You can do multi-vendor tracking manually, but it's one hell of a lot more work (more work even than managing several variant branches in a locally initiated project)! There are not many files, so if you can give me some hints to let a second vendor branch showup on a normal cvs branch and not on the main, I will be very thankfull. Your best approach is to start fresh with the 3.x release in a new module. That is not the way a version control system should work I think. Huh? What do you expect? Black magic? Miracles? No, but it is lot easier for us to find problems if we can easy show the differences between the different vendor releases and our local changes. I don't care if this gives some manual admin work to import it all in the right way. This is CVS we're talking about and while there is some undocumented magic in it, it sure as heck can't pull off miracles for you. The vendor branch support is a simple hack that only really works well in the simplest of cases. When a vendor drastically re-arranges code and files in a new release it is _always_ better to start a new module and to manually carry over ones changes from any old module (if indeed they are still appropriate and necessary). This is probably even documented somewhere (but I'm too lazy to search for you). There are also a lot of files that have minor changes. It's irrelevant whether or not you think this is how a version control system should work -- it _is_ the way CVS works (or doesn't, as the case may be). The way CVS handles file hierarchy changes and renames requires out-of-band information about the programmer's intent be recorded in the commit logs to facilitate subsequent understanding of the change. It is impossible for CVS to guess what this information is in a cvs import, and it's unlikely that even a human could get it right without going to a great deal of trouble (and if you're going to go to that amount of trouble then you should simply avoid cvs import entirely and manage your repository as is you were the vendor, not the consumer). CVS merges most files without conflicts im my situation. There are only a few files that require manual intervention. Perhaps you should try to think about _why_ you are tracking local changes to some vendor code and try to figure out what benefit you gain from using CVS to assist you with this task. Contrast all of this with the more traditional way of managing local changes by creating local patch sets and applying them to new releases, and with schemes which automate this kind of patching, such as the *bsd ports or pkgsrc systems. Easy trouble shooting of sources, check which vendor files are in our released version 2.1 for example. Browsing through cvsweb gives a lot of information. Gerhard. -- Gerhard Ahuis [EMAIL PROTECTED] Unsolicited advertisements subject to $1000 consulting fee. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Howto solve this in cvs ?
[ On Saturday, September 29, 2001 at 23:40:46 (+), Gerhard Ahuis wrote: ] Subject: Re: Howto solve this in cvs ? What is not working well ? I didn't have any problem until this problem arrises. Does it really matter when the problem raises its ugly head? Don't try to use normal branches with vendor branched modules unless you want to invite trouble! (This is unrelated to the following issue too!) It's really not that hard to figure out where the problems arise if you look in detail at how CVS creates branches and how cvs import works. For many of the same reasons it's literally impossible to ever have true multi-vendor support too -- all the benefits of cvs import are completely impossible to achieve with multiple vendor branches. You can do multi-vendor tracking manually, but it's one hell of a lot more work (more work even than managing several variant branches in a locally initiated project)! Your best approach is to start fresh with the 3.x release in a new module. That is not the way a version control system should work I think. Huh? What do you expect? Black magic? Miracles? This is CVS we're talking about and while there is some undocumented magic in it, it sure as heck can't pull off miracles for you. The vendor branch support is a simple hack that only really works well in the simplest of cases. When a vendor drastically re-arranges code and files in a new release it is _always_ better to start a new module and to manually carry over ones changes from any old module (if indeed they are still appropriate and necessary). This is probably even documented somewhere (but I'm too lazy to search for you). It's irrelevant whether or not you think this is how a version control system should work -- it _is_ the way CVS works (or doesn't, as the case may be). The way CVS handles file hierarchy changes and renames requires out-of-band information about the programmer's intent be recorded in the commit logs to facilitate subsequent understanding of the change. It is impossible for CVS to guess what this information is in a cvs import, and it's unlikely that even a human could get it right without going to a great deal of trouble (and if you're going to go to that amount of trouble then you should simply avoid cvs import entirely and manage your repository as is you were the vendor, not the consumer). Perhaps you should try to think about _why_ you are tracking local changes to some vendor code and try to figure out what benefit you gain from using CVS to assist you with this task. Contrast all of this with the more traditional way of managing local changes by creating local patch sets and applying them to new releases, and with schemes which automate this kind of patching, such as the *bsd ports or pkgsrc systems. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Howto solve this in cvs ?
Greg A. Woods [EMAIL PROTECTED] wrote: [ On Friday, September 28, 2001 at 16:34:19 (+), Gerhard Ahuis wrote: ] Subject: Howto solve this in cvs ? The vendor did a complete architecture change and cleanup between 2.x and 3.x. So I created a branch called MySoftBasedOn_2x on which further developments you don't really want a branch -- normal branches don't work well in vendor branched modules. What is not working well ? I didn't have any problem until this problem arrises. Your best approach is to start fresh with the 3.x release in a new module. That is not the way a version control system should work I think. If there is no way to do it with a vendor like import the only thing left is commiting the vendor changes as local changes on the MySoftBasedOn_2x branch. That will work but there is no easy way to distinguish vendor changes and local changes in that case (and I like the easy merging). There must be a better solution, cvs has not dissapointed me until now.. Cheers, Gerhard. -- Gerhard Ahuis [EMAIL PROTECTED] Unsolicited advertisements subject to $1000 consulting fee. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
