Re: Reimporting vendor projects where items have been deleted
On Fri, Mar 23, 2001 at 03:41:12PM -0500, Derek R. Price wrote: > Eric Siegerman wrote: > > [if] the ,v file has an appropriate vendor branch, but the latest > > revision on that branch is marked "dead", then of course the new > > release tag should be added to that dead revision > > No it shouldn't. I defer to your (much) greater knowledge of CVS internals. I suggested this *because* it's what happens with unchanged live files, and it seems cleaner to me to treat unchanged files (whether live or dead) in the same way, unless there are reasons to do otherwise -- "make sure special cases really are special" and all that. I'll take your word for it that there are indeed reasons to treat these cases differently. > > > Should this be based on the import branch number, rather than > > name? > > Absolutely not. If the same vendor branch name was used in both cases then it should > already be an error if they point at different branches. Do you mean where someone does this? cvs import foo vendor1 release1 cvs import -b 1.1.3 foo vendor1 release2 ^ [sic] I wasn't trying to address this case, which is clearly an error, but rather Nathan's Case 2 below. I guess I was unclear. Sorry. On Fri, Mar 23, 2001 at 12:53:25PM -0800, Nathan Herring wrote: > CASE 1: Vendors using different vendor branches (not just names). > [importing on vendor branch A does *not* check "dead" > revisions into vendor branch B] No argument here! > CASE 2: Vendors using different names, but same vendor branches. To summarize: cvs import foo vendor1 release1 cvs import foo vendor2 release2 with no -b option either time. After looking into this more closely, it seems each of us is right some of the time :-) Under Nathan's assumption -- that this happened because a user was trying to create a second vendor branch but forgot the -b -- he's right; his proposed behaviour works better. But there's another way this situation can arise (which is the one I was thinking of when I proposed my change): if the user was trying to import a new release into an existing vendor branch, but mistyped the tag name. I'll call this "case 3", even though it's isomorphic to case 2. In case 3, my proposed behaviour works better -- if a file is in release1 but not in release2, the user does *not* want it to appear on what they intended to be the *only* vendor branch. Thus, it shouldn't appear on either actual branch, and my way, it doesn't. But note: - Cases 2 and 3 are both due to user error - Both of them have other problems, which keep them from doing what the user wanted (as opposed to what they mistakenly asked for :-) Thus, it doesn't seem to matter much which way this particular decision goes; it comes down to arguing over which error users are more likely to make. Unless, of course, there are more *non-error* cases; if there are, what's right for those should win over both cases 2 and 3. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Eric wrote: >Note that if all of these conditions are met except the last one, >ie. the ,v file has an appropriate vendor branch, but the latest >revision on that branch is marked "dead", then of course the new >release tag should be added to that dead revision -- as happens >now for an unchanged "live" file. I'm not sure I necessarily agree with this. For most purposes, a file missing a static tag is equivalent to a file containing a static tag to a dead revision. Mostly, it would just take up room on the server. If you can think of a real reason to have this, let me know. >But perhaps that's what Nathan meant by: >> AND that branch has the same version as the branch version specified >> on import > >in which case, all I'm questioning is whether the following >condition should go away: >> AND repository file has a branch with the same name as the vendor-tag >> argument I ended up sending the e-mail in a half revised state accidentally, so I didn't end up explaining why we need this. First, thanks for pointing out my errors! Here are two cases we wish to get right: CASE 1: Vendors using different vendor branches (not just names). $ echo 1>vendor1 $ cvs import -m vendor1_version1 tst vendor1 vendor1_version1 N tst/vendor1 No conflicts created by this import $ rm vendor1 $ echo 2>vendor2 $ cvs import -m vendor2_version1 -b 1.1.3 tst vendor2 vendor2_version1 N tst/vendor2 No conflicts created by this import $ rm vendor2 $ cvs import -D -m vendor1_version2 tst vendor1 vendor1_version2 R tst/vendor1 No conflicts created by this import This deletes file vendor1 because a file exists on the vendor branch we're importing to (1.1.1), and doesn't exist in the import list. This doesn't delete file vendor2 because it doesn't contain the branch 1.1.1. CASE 2: Vendors using different names, but same vendor branches. $ echo 1>vendor1 $ cvs import -m vendor1_version1 tst vendor1 vendor1_version1 N tst/vendor1 No conflicts created by this import $ rm vendor1 $ echo 2>vendor2 $ cvs import -m vendor2_version1 tst vendor2 vendor2_version1 N tst/vendor2 No conflicts created by this import NOTE: at this point vendor1 == vendor2 == 1.1.1 $ rm vendor2 $ cvs import -D -m vendor1_version2 tst vendor1 vendor1_version2 R tst/vendor1 No conflicts created by this import With the heuristic I described, this would also do the "right" thing, since it checks the name of the vendor branch as well as the branch version number. You don't want to delete the vendor2 files, and the only way to make sure it's not a vendor1 file is to make sure it doesn't have the vendor1 branch tag. This is somewhat important, as most people don't generally realise that if they specify a different vendor name, they won't get a different vendor branch, but rather they'll be on the same vendor branch with the new tag assigned. You can end up royally screwed if you have different vendors with the same file that you import into the same location, failing to specify different branch versions, and then use the delete feature on a subsequent import where the file doesn't exist. However, this is certainly an extreme case, and not the normal. nh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Eric Siegerman wrote: > Note that if all of these conditions are met except the last one, > ie. the ,v file has an appropriate vendor branch, but the latest > revision on that branch is marked "dead", then of course the new > release tag should be added to that dead revision -- as happens > now for an unchanged "live" file. No it shouldn't. The only time I can see _any_ reason to do this is for the tag used in the import during which the file was actually remove and then only to mark the import which deleted the file. This information should more likely be in the log message. The dead revision really only needs to be attached to the branch. > Should this be based on the import branch number, rather than > name? That is: if, in the above example, branch-tags "vendor1" > and "vendor2" both referred to branch 1.1.1, then they'd be > considered identical for this purpose; vendor2_file1 *would* be > deleted during the "third" import. But if "vendor1" and > "vendor2" referred to different branches, eg. the vendor2 import > had been: > $ cvs import -m second -b 1.1.3 tst vendor2 vendor2_v1 > then, as Nathan says, vendor2_file1 would *not* be deleted during > the "third" import -- indeed, in this specific case, it wouldn't > have to be deleted, since it wouldn't be on branch 1.1.1 in the > first place. Absolutely not. If the same vendor branch name was used in both cases then it should already be an error if they point at different branches. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- The Gothic idea that we were to look backwards instead of forwards for the improvement of the human mind, and to recur to the annals of our ancestors for what is most perfect in government, in religion and in learning, is worthy of those bigots in religion and government by whom it has been recommended, and whose purposes it would answer. But it is not an idea which this country will endure. - Thomas Jefferson to Joseph Priestley, 1800 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Eric Siegerman wrote: > On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote: > > Basically, import would have to look up the tip of the vendor branch > > before execution to obtain the list of files present during the last > > import. > > Not "before execution". Instead, "import" turns into a classic I have no idea what you are talking about, but I think my method is the easiest. Anything else would be overkill, I'm pretty sure, and I think the checkout of the branch tip before import is unavoidable when implementing this feature (barring currently unimplemented caches & metadata...). Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- 170. If you try to fail, and succeed, which have you done? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote: > Nathan Herring wrote: > > Import knows the name and branch version of the vendor branch, has a > > list of files to import, and has a list of files already in the > > repository. This is all it needs to know. Now use the following > > heuristic: > > Basically, import would have to look up the tip of the vendor branch > before execution to obtain the list of files present during the last > import. Not "before execution". Instead, "import" turns into a classic merge(*) -- which I guess "update" already is. So one has to add a scan of the repository directory, and the reading of any repository files that aren't in the directory being imported, but it's still only one-pass. * I mean "merge" here in the traditional "sort/merge" sense, not CVS's "merging revisions" sense -- don't you love overloaded jargon? -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Thu, Mar 22, 2001 at 10:30:19PM -0800, Nathan Herring wrote: > Larry writes: > >How is import supposed to know to do that, though? > > IF import file does not exist, > AND repository file does exist, > AND repository file has a branch with the same name as the vendor-tag > argument > AND that branch has the same version as the branch version specified > on import > AND the most recent revision on the vendor-tag branch is not marked > dead, > THEN > create a new version on the vendor-tag branch marked as dead > END IF What he said! Note that if all of these conditions are met except the last one, ie. the ,v file has an appropriate vendor branch, but the latest revision on that branch is marked "dead", then of course the new release tag should be added to that dead revision -- as happens now for an unchanged "live" file. > P.S. Here's a second example: > > $ mkdir vendor1 > $ cd vendor1 > $ echo 1>vendor1_file1 > $ echo 2>vendor1_file2 > $ cvs import -m first tst vendor1 vendor1_v1 > N tst/vendor1_file1 > N tst/vendor1_file2 > > No conflicts created by this import > > $ mkdir ../vendor2 > $ cd ../vendor2 > $ echo 1>vendor2_file1 > $ cvs import -m second tst vendor2 vendor2_v1 > N tst/vendor2_file1 > > $ cd ../vendor1 > $ rm vendor1_file1 > $ cvs import -D -m third tst vendor1 vendor1_v2 > R tst/vendor1_file1 > U tst/vendor1_file2 > > No conflicts created by this import > > NOTE: It didn't remove vendor2_file1 [NB: this actually said "vendor2_file2"; > I've corrected what I assume was a typo -ES ], because, depsite the fact that the > import file did not exist, the repository file did not have the original > vendor1 tag, and so CVS assumes it wasn't part of this vendor's import > and leaves it alone. This is the only part I question -- and I do mean "question"; I'm not asserting that it's wrong, but wondering whether it might be, and asking people to think about it. Should this be based on the import branch number, rather than name? That is: if, in the above example, branch-tags "vendor1" and "vendor2" both referred to branch 1.1.1, then they'd be considered identical for this purpose; vendor2_file1 *would* be deleted during the "third" import. But if "vendor1" and "vendor2" referred to different branches, eg. the vendor2 import had been: $ cvs import -m second -b 1.1.3 tst vendor2 vendor2_v1 then, as Nathan says, vendor2_file1 would *not* be deleted during the "third" import -- indeed, in this specific case, it wouldn't have to be deleted, since it wouldn't be on branch 1.1.1 in the first place. But perhaps that's what Nathan meant by: > AND that branch has the same version as the branch version specified > on import in which case, all I'm questioning is whether the following condition should go away: > AND repository file has a branch with the same name as the vendor-tag > argument -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Nathan Herring wrote: > Larry writes: > >How is import supposed to know to do that, though? > > Import knows the name and branch version of the vendor branch, has a > list of files to import, and has a list of files already in the > repository. This is all it needs to know. Now use the following > heuristic: Yeah. Basically, import would have to look up the tip of the vendor branch before execution to obtain the list of files present during the last import. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Re: Graphics A picture is worth 10k words, but only if the words describe the picture. Very few arbitrary sets of 10k words can be adequately replaced with a picture. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Larry writes: >How is import supposed to know to do that, though? Import knows the name and branch version of the vendor branch, has a list of files to import, and has a list of files already in the repository. This is all it needs to know. Now use the following heuristic: IF import file does not exist, AND repository file does exist, AND repository file has a branch with the same name as the vendor-tag argument AND that branch has the same version as the branch version specified on import AND the most recent revision on the vendor-tag branch is not marked dead, THEN create a new version on the vendor-tag branch marked as dead END IF NOTE: You don't touch files in this case that are missing the original vendor-tag branch tag, as they were never part of a previous import for this vendor (at least as far as you specified). NOTE: If you remove the original vendor-tag from the file, it will no longer assume you've imported it, and if you reimport using this feature, it will not mark it dead, as the heuristic no longer has any way to determine that it was part of a previous import (for this vendor). However, I doubt many people are going to do this accidentally or have some strange reason to do this. Now, it may be that the current code (which I have not inspected) only looks through the import list and makes changes to the repository. In that case, you'd have to have a second iteration that looks through the repository list and matches it up against the import list, and in the case of missing files, checking to see whether it (1) had the vendor branch Here is your example altered as I would see it with the above new functionality. I'm using -D as the special new option for this feature. I'm using 'R' as the code for I've removed this file from the repository.: $ echo file1 >file1 $ echo file2 >file2 $ cvs import -m first tst NET FIRST N tst/file1 N tst/file2 No conflicts created by this import $ rm file1 $ echo file3 >file3 $ cvs import -D -m second tst NET SECOND N tst/file3 R tst/file1 U tst/file2 No conflicts created by this import Now, file1 would have revisions 1.1 (alive), 1.1.1.1 (alive), and 1.1.1.2 (dead). Furthermore, if you were to check out tst to either NET or SECOND, you'd get exactly what you wanted. nh P.S. Here's a second example: $ mkdir vendor1 $ cd vendor1 $ echo 1>vendor1_file1 $ echo 2>vendor1_file2 $ cvs import -m first tst vendor1 vendor1_v1 N tst/vendor1_file1 N tst/vendor1_file2 No conflicts created by this import $ mkdir ../vendor2 $ cd ../vendor2 $ echo 1>vendor2_file1 $ cvs import -m second tst vendor2 vendor2_v1 N tst/vendor2_file1 $ cd ../vendor1 $ rm vendor1_file1 $ cvs import -D -m third tst vendor1 vendor1_v2 R tst/vendor1_file1 U tst/vendor1_file2 No conflicts created by this import NOTE: It didn't remove vendor2_file2, because, depsite the fact that the import file did not exist, the repository file did not have the original vendor1 tag, and so CVS assumes it wasn't part of this vendor's import and leaves it alone. -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 8:59 PM To: Eric Siegerman Cc: [EMAIL PROTECTED] Subject: Re: Reimporting vendor projects where items have been deleted Eric Siegerman writes: > > If, as someone suggested, "import" were to check in a "dead" > revision on the vendor branch, I presume both versions would > work. How is import supposed to know to do that, though? -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin ___ 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: Reimporting vendor projects where items have been deleted
Eric Siegerman writes: > > If, as someone suggested, "import" were to check in a "dead" > revision on the vendor branch, I presume both versions would > work. How is import supposed to know to do that, though? -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Thu, Mar 22, 2001 at 05:18:12PM -0500, Larry Jones wrote: > You have to use the new > release tag (it's the absence of that tag that indicates that the file > should be deleted). So, instead of suggesting -jNET:yesterday -jNET, > CVS should be suggesting -jNET:yesterday -jSECOND, for example. If, as someone suggested, "import" were to check in a "dead" revision on the vendor branch, I presume both versions would work. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Title: RE: Reimporting vendor projects where items have been deleted >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Thursday, March 22, 2001 2:18 PM >should be deleted). So, instead of suggesting -jNET:yesterday -jNET, >CVS should be suggesting -jNET:yesterday -jSECOND, for example. And it >should suggest it reguardless of whether there are any >conflicts or not. Is there any reason it shouldn't say something to indicate that "yesterday" in this suggested command line is really meant to be some time between this import and the one before? Something like: Where "yesterday" should be replaced by some time between this import and the one before, if yesterday is not in that range. Jerry
Re: Reimporting vendor projects where items have been deleted
Laine Stump writes: > > If you want to modify your statement to say "Doing a merge using the > tags placed on the branch at the time of the last two imports" (or > something similar), we'll be in complete agreement, but currently the > merge that cvs suggests does nothing of the sort, so either your > statement is incorrect, or there is a bug in cvs. My apologies -- you're absolutely right. You have to use the new release tag (it's the absence of that tag that indicates that the file should be deleted). So, instead of suggesting -jNET:yesterday -jNET, CVS should be suggesting -jNET:yesterday -jSECOND, for example. And it should suggest it reguardless of whether there are any conflicts or not. -Larry Jones Girls are like slugs -- they probably serve some purpose, but it's hard to imagine what. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > That's great, but your example doesn't use the tags normally suggested > > in the results of imports, eg "-j NET:yesterday -j NET" (which in this > > case wouldn't work anyway because it had been less than a day between > > imports, but that's beside the point). > > No, but it shows that the basic functionality does work. If it didn't > work for you, then either you're running an old version of CVS. Nope. 1.11 server, straight from (post-1.11) CVS on client. > or you did something wrong. Unless the cvs import command is giving "wrong" instructions, I am not doing anything "wrong". CVS is not performing as you described in your original email message on the subject. Note the emphasized phrase below: [EMAIL PROTECTED] (Larry Jones) writes: > Doing the merge that CVS suggests when there are conflicts (even if ^ > there aren't any conflicts) will mark the appropriate files for > deletion. Committing the results of the merge will then delete them. If you want to modify your statement to say "Doing a merge using the tags placed on the branch at the time of the last two imports" (or something similar), we'll be in complete agreement, but currently the merge that cvs suggests does nothing of the sort, so either your statement is incorrect, or there is a bug in cvs. As for your example, it is *not* doing the merge that the cvs import command suggests. It names specific tags (eg -j FIRST -j SECOND), while the cvs import command recommends using two *branch* tags, the first with a date offset specifier (eg -jNET:yesterday -jNET). When I use specific tags as you did in your example, it does of course work as you say (as I said in my last reply). However, when I use branch tags as suggested by cvs import, no files are deleted. Following is an example based on yours that demonstrates what I'm talking about - note that 1) I used the merge command recommended by cvs import when it found a conflict, and 2) nothing is marked for deletion, as your message claimed would happen. (One small deviation - I used "-jNET:'2 minutes ago'" rather than "-jNET:yesterday" since it had been less than a day since the first import. The results would be the same if I waited for another day and then used "-jNET:yesterday" however. If you remain unconvinced, I can do the same command over again with a one day wait in the middle ;-)) # date; echo file1 >file1; echo file2 >file2; cvs import -m first tst NET FIRST Thu Mar 22 15:08:46 EST 2001 N tst/file1 N tst/file2 No conflicts created by this import # checkout a workspace and modify file2 to create a conflict on next import # cvs co tst U tst/file1 U tst/file2 # cd tst # echo more file2 >>file2 # cvs commit -m"local commit" Checking in file2; /vol/cvsroot/tst/file2,v <-- file2 new revision: 1.2; previous revision: 1.1 done # cd .. # rm -rf tst # make some changes in dir to be imported - remove file1, modify file2 # so there will be a conflict, create file3 # rm file1 # echo more imported file2 >>file2 # echo file3 >file3 # date; cvs import -m second tst NET SECOND Thu Mar 22 15:11:27 EST 2001 N tst/file3 C tst/file2 1 conflicts created by this import. Use the following command to help the merge: ===> cvs checkout -jNET:yesterday -jNET tst # Note that at this point, more than two minutes have passed since the # first import, and less than two minutes since the 2nd (only a few # seconds, actually). The fact that it gives us the change to file2 # from the vendor branch verifies that we have the timing correct. # cvs suggested "-jNET:yesterday -jNET", but we know that it hasn't been # a full day yet, so we use '2 minutes ago' as the time specifier. ===> # cvs co -jNET:'2 minutes ago' -jNET tst U tst/file1 U tst/file2 RCS file: /vol/cvsroot/tst/file2,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into file2 rcsmerge: warning: conflicts during merge U tst/file3 # (Note - no messages indicating files scheduled for deletion) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Laine Stump writes: > > That's great, but your example doesn't use the tags normally suggested > in the results of imports, eg "-j NET:yesterday -j NET" (which in this > case wouldn't work anyway because it had been less than a day between > imports, but that's beside the point). No, but it shows that the basic functionality does work. If it didn't work for you, then either you're running an old version of CVS or you did something wrong. -Larry Jones These child psychology books we bought were such a waste of money. -- Calvin's Mom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] (Larry Jones) writes: > [ example of cvs import followed by merge auto-deleting files ] That's great, but your example doesn't use the tags normally suggested in the results of imports, eg "-j NET:yesterday -j NET" (which in this case wouldn't work anyway because it had been less than a day between imports, but that's beside the point). When I do *exactly* the command suggested by cvs import, no deletes are scheduled, even though it has been more than a day since my last import. (Yes, I just tried it again to double-check). Here's what you first said: [EMAIL PROTECTED] (Larry Jones) writes: > Doing the merge that CVS suggests when there are conflicts (even if > there aren't any conflicts) will mark the appropriate files for > deletion. Committing the results of the merge will then delete them. That still is incorrect - apparently this is only done if you specify exact tags in the command; it doesn't happen if you use branch tags and/or date specifications (yesterday, two days ago, etc) as the command suggested by cvs import (ie "the merge that CVS suggests") does. I'll leave it up to you to decide whether this is a bug in CVS, or you misspoke ;-) Anyway, I'm glad to know that there is a way to make it work, even if it doesn't work when I follow CVS' instructions. [EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > This was the first import in about 6 months. All the differences in > > files, and new files, were merged correctly. However, your message had > > indicated that file deletions would also be marked when I did the > > merge; this was not the case. > > bash-2.02$ echo file1 >file1 > bash-2.02$ echo file2 >file2 > bash-2.02$ cvs import -m first tst NET FIRST > N tst/file1 > N tst/file2 > > No conflicts created by this import > > bash-2.02$ rm file1 > bash-2.02$ echo file3 >file3 > bash-2.02$ cvs import -m second tst NET SECOND > N tst/file3 > U tst/file2 > > No conflicts created by this import > > bash-2.02$ cvs co -j FIRST -j SECOND tst > cvs checkout: Updating tst > U tst/file1 > ==> cvs checkout: scheduling tst/file1 for removal > U tst/file2 > U tst/file3 > bash-2.02$ cd tst > bash-2.02$ cvs ci -m merge > cvs commit: Examining . > ==> Removing file1; > ==> /public/CVS/tst/file1,v <-- file1 > ==> new revision: delete; previous revision: 1.1.1.1 > ==> done > > -Larry Jones > > I'm so disappointed. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Laine Stump writes: > > This was the first import in about 6 months. All the differences in > files, and new files, were merged correctly. However, your message had > indicated that file deletions would also be marked when I did the > merge; this was not the case. bash-2.02$ echo file1 >file1 bash-2.02$ echo file2 >file2 bash-2.02$ cvs import -m first tst NET FIRST N tst/file1 N tst/file2 No conflicts created by this import bash-2.02$ rm file1 bash-2.02$ echo file3 >file3 bash-2.02$ cvs import -m second tst NET SECOND N tst/file3 U tst/file2 No conflicts created by this import bash-2.02$ cvs co -j FIRST -j SECOND tst cvs checkout: Updating tst U tst/file1 ==> cvs checkout: scheduling tst/file1 for removal U tst/file2 U tst/file3 bash-2.02$ cd tst bash-2.02$ cvs ci -m merge cvs commit: Examining . ==> Removing file1; ==> /public/CVS/tst/file1,v <-- file1 ==> new revision: delete; previous revision: 1.1.1.1 ==> done -Larry Jones I'm so disappointed. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] (Larry Jones) writes: > Laine Stump writes: > > > > I'm glad this message came by again - I just did an import and saw the > > that the behavior described by Larry below did not occur. Nothing is > > marked for deletion by CVS either during the import or during > > execution of the suggested "merging checkout" afterwards. > > The suggested merge command assumes that you won't import more than one > release per day -- if you do, you need to use the explicit release tags > for the merge rather than the "vendor" and "vendor:yesterday" that CVS > suggests. (CVS can't suggest that itself since it has no way to know > what release tag you used the last time.) This was the first import in about 6 months. All the differences in files, and new files, were merged correctly. However, your message had indicated that file deletions would also be marked when I did the merge; this was not the case. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Laine Stump writes: > > I'm glad this message came by again - I just did an import and saw the > that the behavior described by Larry below did not occur. Nothing is > marked for deletion by CVS either during the import or during > execution of the suggested "merging checkout" afterwards. The suggested merge command assumes that you won't import more than one release per day -- if you do, you need to use the explicit release tags for the merge rather than the "vendor" and "vendor:yesterday" that CVS suggests. (CVS can't suggest that itself since it has no way to know what release tag you used the last time.) -Larry Jones Oh, now don't YOU start on me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
Eric Siegerman wrote: >On Tue, Mar 20, 2001 at 05:20:25PM -0800, Stephen Rasku wrote: >> Nathan Herring wrote: >> >I'd like to have the option on successive imports to mark as deleted any >> >files that previously existed on that vendor branch that are not in the >> >import. >> >> I don't see why this is necessary. If you do: >> >> cvs co -r vendor-v2 themodule >> >> It will not check out any modules that don't have the vendor-v2 tag. > >True. > >> For all intents and purposes it is deleted. > >Not true. If you do: > cvs co -r vendor themodule > >you *will* get the deleted files. You shouldn't. > Oh, yeah. That's right (you will and you shouldn't). -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
> cvs co -r vendor-v2 themodule We actually check out themodule (usually we import to themodule/somevendor) to the trunk, not to any particular tag. Thus, this doesn't really work for us. > cvs co -j vendor-v1 -j vendor-v2 themodule > > cvs ci themodule Larry suggested this one. This works OK. One of our problems is that our client (MacCVSPro) doesn't actually schedule files for deletion with the merge, so there's no easy way to check in the deleted files. We, thus, need to perform the import in the client, and then do the merge, conflict resolution, and check in on the server (annoying, but possible). However, it seems that it is all a completely unnecessary step, since you already know the name of the vendor branch, and you can check whether any particular file in the import location already has that branch tag, but is not part of the import. In that case, you can just put another version on that vendor branch that is "deleted", and optionally tag it with the version tag used during import. No extra user steps required. Furthermore, everything is nice and tidy: the deleted version is on the branch, so it looks like the vendor deleted it (as indeed they did), as opposed to on the trunk, which looks like one of us deleted it. I did some manual ,v file editing to see if I could create such an item. I did, and it works like you'd expect. (I realise that this is a low utility addition. :) nh -Original Message- From: Stephen Rasku [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 5:20 PM To: Nathan Herring; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Reimporting vendor projects where items have been deleted Nathan Herring wrote: > >Is there some place to make feature requests such as this one? > >I'd like to have the option on successive imports to mark as deleted any >files that previously existed on that vendor branch that are not in the >import. > >To wit, > >cvs import -m "version 1" themodule vendor vendor-v1 >>cvs creates themodule/file, with versions 1.1.1.1, 1.1, and "vendor" >vendor branch 1.1.1. >cvs import -m "version 2" themodule vendor vendor-v2 >>cvs notices that file isn't in the import, but it is on the "vendor" >branch, and so makes a new version 1.1.1.2 marking the file as deleted. > I don't see why this is necessary. If you do: cvs co -r vendor-v2 themodule It will not check out any modules that don't have the vendor-v2 tag. For all intents and purposes it is deleted. If you are making modifications to the source, then you should merge the changes to the head: cvs co -j vendor-v1 -j vendor-v2 themodule cvs ci themodule -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
On Tue, Mar 20, 2001 at 05:20:25PM -0800, Stephen Rasku wrote: > Nathan Herring wrote: > >I'd like to have the option on successive imports to mark as deleted any > >files that previously existed on that vendor branch that are not in the > >import. > > I don't see why this is necessary. If you do: > > cvs co -r vendor-v2 themodule > > It will not check out any modules that don't have the vendor-v2 tag. True. > For all intents and purposes it is deleted. Not true. If you do: cvs co -r vendor themodule you *will* get the deleted files. You shouldn't. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
I'm glad this message came by again - I just did an import and saw the that the behavior described by Larry below did not occur. Nothing is marked for deletion by CVS either during the import or during execution of the suggested "merging checkout" afterwards. Actually, there are times when this behavior is *good*, since it allows me to import "partial code drops" from 3rd parties who just send me a few files for a quick bugfix, rather than a full release. In most cacses it would be nice, though... > [EMAIL PROTECTED] writes: > > > > If I am importing a vendor project for the second or subsequent times > > on the same vendor branch, how can I mark the files that no longer > > exist in the vendor projects as deleted on the vendor branch? > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Doing the merge that CVS suggests when there are conflicts (even if > there aren't any conflicts) will mark the appropriate files for > deletion. Committing the results of the merge will then delete them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Nathan Herring wrote: > >Is there some place to make feature requests such as this one? > >I'd like to have the option on successive imports to mark as deleted any >files that previously existed on that vendor branch that are not in the >import. > >To wit, > >cvs import -m "version 1" themodule vendor vendor-v1 >>cvs creates themodule/file, with versions 1.1.1.1, 1.1, and "vendor" >vendor branch 1.1.1. >cvs import -m "version 2" themodule vendor vendor-v2 >>cvs notices that file isn't in the import, but it is on the "vendor" >branch, and so makes a new version 1.1.1.2 marking the file as deleted. > I don't see why this is necessary. If you do: cvs co -r vendor-v2 themodule It will not check out any modules that don't have the vendor-v2 tag. For all intents and purposes it is deleted. If you are making modifications to the source, then you should merge the changes to the head: cvs co -j vendor-v1 -j vendor-v2 themodule cvs ci themodule -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Is there some place to make feature requests such as this one? I'd like to have the option on successive imports to mark as deleted any files that previously existed on that vendor branch that are not in the import. To wit, cvs import -m "version 1" themodule vendor vendor-v1 >cvs creates themodule/file, with versions 1.1.1.1, 1.1, and "vendor" vendor branch 1.1.1. cvs import -m "version 2" themodule vendor vendor-v2 >cvs notices that file isn't in the import, but it is on the "vendor" branch, and so makes a new version 1.1.1.2 marking the file as deleted. Thx, nh -Original Message- From: Nathan Herring Sent: Sunday, February 25, 2001 2:43 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: Reimporting vendor projects where items have been deleted Right, but you end up with version 1.2 on the main trunk marked as deleted, and it doesn't have the vendor tag for version 2. So, you suggest: cvs import -m "version 2" themodule vendor vendor-v2 cvs co -j vendor-v1 -j vendor-v2 themodule cvs ci -m "remove vendor files" cvs tag vendor-v2 This is OK, but it'd be better to have the option to auto-delete those files as version 1.1.1.2 on the vendor branch. nh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 8:38 PM To: Nathan Herring Cc: [EMAIL PROTECTED] Subject: Re: Reimporting vendor projects where items have been deleted [EMAIL PROTECTED] writes: > > If I am importing a vendor project for the second or subsequent times > on the same vendor branch, how can I mark the files that no longer > exist in the vendor projects as deleted on the vendor branch? Doing the merge that CVS suggests when there are conflicts (even if there aren't any conflicts) will mark the appropriate files for deletion. Committing the results of the merge will then delete them. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Reimporting vendor projects where items have been deleted
Right, but you end up with version 1.2 on the main trunk marked as deleted, and it doesn't have the vendor tag for version 2. So, you suggest: cvs import -m "version 2" themodule vendor vendor-v2 cvs co -j vendor-v1 -j vendor-v2 themodule cvs ci -m "remove vendor files" cvs tag vendor-v2 This is OK, but it'd be better to have the option to auto-delete those files as version 1.1.1.2 on the vendor branch. nh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 8:38 PM To: Nathan Herring Cc: [EMAIL PROTECTED] Subject: Re: Reimporting vendor projects where items have been deleted [EMAIL PROTECTED] writes: > > If I am importing a vendor project for the second or subsequent times > on the same vendor branch, how can I mark the files that no longer > exist in the vendor projects as deleted on the vendor branch? Doing the merge that CVS suggests when there are conflicts (even if there aren't any conflicts) will mark the appropriate files for deletion. Committing the results of the merge will then delete them. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] writes: > > If I am importing a vendor project for the second or subsequent times > on the same vendor branch, how can I mark the files that no longer > exist in the vendor projects as deleted on the vendor branch? Doing the merge that CVS suggests when there are conflicts (even if there aren't any conflicts) will mark the appropriate files for deletion. Committing the results of the merge will then delete them. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Reimporting vendor projects where items have been deleted
If I am importing a vendor project for the second or subsequent times on the same vendor branch, how can I mark the files that no longer exist in the vendor projects as deleted on the vendor branch? It seems that cvs just ignores them and doesn't update those files on the branch. What I'd like to see is something like version 1.1.1.1 exists, but version 1.1.1.2 is marked as deleted. Can I do this without some extra scripting to manually hack at the ,v files? Thanks, nh ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
