Bugzilla – Full Text Bug Listing
| Summary: | Keep file version when moving from one directory to another | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | Team | Assignee: | Platform Team Inbox <platform-team-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | Keywords: | helpwanted |
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alex Blewitt
Its an interesting idea. The only catch is the following from: http://www.cvshome.org/docs/manual/cvs_4.html#SEC47 "Note that the number you specify with `-r' must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot `cvs commit -r 1.3'." So for the case of moving to a new directory structure, this would work nicely. But wrt. your comment, >>Commit mechanism to preserve versions (+1) it would be great The cases where one could make use of it are less than one would like. Yes, so rather than doing it as part of a set of other commits, the add/delete would have to be factored out into its own commit unit, separate from other commits that are happening at that time. Each move could then guarantee that the moved file was given its own version, rather than having all version numbers spread across multiple files that may be in the same user-commit action. I don't understand comment #1 >> Commit mechanism to preserve versions (+1) it would be great > The cases where one could make use of it are less than one would like. I meant this to mean that when moving README.txt (1.5) to newdir/README.txt, that the new version in README.txt was 1.6 (following rules for the standard CVS commit mechanism of incrementing the right-most-digit). If you had a bunch of moves (adds/deletes) then if the user commited the whole lot, it would need to go through as separate CVS commits: If the user committed (- deleted, + moved, * changed) - /README.txt (1.5) * /Updated.txt (1.4) - /old/file (1.3) + /new/README.txt + /new/file then this would have to go through as individual updates: cvs -m delete README.txt -m "Moved to /new" cvs -m delete old/file -m "Moved to /new" cvs commit README.txt old/file Updated.txt cvs add new/README.txt cvs commit -r 1.6 new/README.txt (1.5+1->1.6) cvs add new/file cvs commit -r 1.4 new/file (1.3+1->1.4) This is possible in the straightforward case but there are some cases were it fails (i.e. the move recreates a file whose revision was higher than the source file when it was deleted). However, my main objection to this is that I don't see what purpose it serves. Even if the revision was preserved, in CVS there is no link between the old and new files so I can't see the point of having a relationship between the revision numbers. For this reason, I am closing this request. It could be argued that such improved facilities could be added on top of CVS. However, this is beyond what is planned for the Eclipse CVS client. However, there has been some discussion about defining a CVS API that would allow others to create such tools as addition plugins. If you are interested in such an API, you can voice your interest and ideas on the platform-vcm-dev mailing list (where any discussion about such an API would take place). > However, my main objection to this is that I don't see what purpose it serves. Allow me to come up with some examples :-) Firstly, I've had an experience when refactoring classes from one package to another. At first, I split several subcomponents out into different packages (and reset a whole bunch of classes back to 1.1). Nearer the end of the project, there were only a couple of classes in one subpackage that I decided to merge with another existing package. Again, the version numbers were set back to 1.1 after this merge. Secondly, I've had a previous project (before Eclipse's time, when Visual Age was around) where due to copyright reasons the internal name of the project was changed to another name, and all the packages had to be re-prefixed. This kind of massive-scale change would result in the entire re-setting of the project's types back to revision 1.1, whatever their previous state (in this case, the prefix was a completely different directory structure). > Even if the revision was preserved, in CVS there is no link between the old > and new files so I can't see the point of having a relationship between the > revision numbers. It is true that there is no relation between the file in the old directory and the file in the new directory in CVS. However, that does not mean there is no relation between the files outside of CVS. Further, the purpose of the -r flag in CVS is to explicitly give a file a new version/revision. It does not necessarily follow that if a resource exists in CVS that if release 1.n exists in CVS then 1.1---1.(n-1) also exist. Some source code control tools have the ability of 'forgetting' intermediate versions (say, to improve disk storage space). So it is possible to have a file revision 1.1, 1.2 and then 1.7 without any intermediate revisions (1.3-6) under CVS storage. I would also like to challenge your assumption that the revision number is meaningless outside of CVS. That simply isn't the case; many bug reports are filed and noted with the revision of the class that they were fixed in. Having a bug filed in a bug-tracking system against revision 1.7 of a class isn't going to help if the class is moved and the revision is set back to 1.1 again. Is the bug fixed? Well, it would seem so, but the bug reporting notes would refer to the old number. > (i.e. the move recreates a file whose revision was higher than the source > file when it was deleted). Well, in this case if the original revision is 1.x and it would have been recreated as 1.(x+1) but there used to exist a revision 2.0 then 2.1 is still going to be higher than 1.1 which is what currently happens (when there is no resource). My argument is that revisions should never go down, only up and this should be preserved even when resources are moved between packages. Lastly, your objections practically all disappear if the class version is migrated to (say) 2.1 instead of 1.1. In this case, the revision number is still increasing over the old revision, and the new number may explicitly be documented that revision 1.x lived in package y. [In fact, I would argue that the move process should automatically add the comment that Resource X has been moved to directory Y for human, if not automatic, reference.] It may also be more understandable that since there s a 2.1 the previous 1.x revisions may not be available. > For this reason, I am closing this request. I would like this to be reconsidered, or at least flagged RESOLVED LATER rather than a blanket WONTFIX. Although the last commenter may not see the point of having this feature in, I believe it would be a very useful one and certainly hope that with respect to commenting/revision fixes and package renames that it is understandable that some people would like this feature. It does not necessarily have to be a default action; there are three ways that such a change could happen: o Continue to use existing process o Use 1.x -> 1.x+1 in new directory o Use 1.x -> 2.1 in new directory Sorry, I was just trying to be realistic. It's not that I don't see the point of your feature request (given an explicit linkage between the files involved), it's just that given our current workload and the number of outstanding bugs against our component, there is little chance of this ever being done by the Team team. That's not to say that we will not add support for the -r flag on commit. I believe that this is something we MUST do at some point. This, along with a CVS API (something else we hope to do) would allow others, such as yourself, who do see a need for a facility such as the one you propose to contribute it to the community. Since you feel so strongly about it, I am happy to mark it Resolved Later. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |