Bug 74752 - [Operations] Version tagging should exclude added files
Summary: [Operations] Version tagging should exclude added files
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: CVS (show other bugs)
Version: 3.0   Edit
Hardware: PC Linux
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: platform-cvs-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2004-09-23 05:48 EDT by Jean Couillaud CLA
Modified: 2019-09-06 16:16 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean Couillaud CLA 2004-09-23 05:48:37 EDT
There is a simple case in which it would be really great to have that.
If you do a cvs add (Add to version control) and find after the cvs add is done
that you needed, for instance, to do put a tag on the directory containing the
added file, you are doomed.
You have to modify the CVS/Entries yourself on the filesystem to undo the cvs add.

The cvs rm is the only way to undo a cvs add before the commit and cvs rm is not
directly accessible in the Team context submenu. AFAIK, it is only called when a
shared file is deleted.
Comment 1 Michael Valenta CLA 2004-09-23 08:32:15 EDT
So what your saying is that, because CVS tagging doesn't work as the user 
would expect, we should allow a resource to be removed from version control so 
it can be re-added after the tag is applied. I think a better solution would 
be to fix the way tag works so that added file that have not been committed 
are skipped. What to do with deleted files shoudl also be considered.
Comment 2 Jean Couillaud CLA 2004-09-23 09:43:01 EDT
I do not know ... If you give the possibility to add a resource to version
control, there is no point in not allowing to remove a resource from version
control.
Maybe the solution might be to remove the add to version control since eclipse
prompts the user before the commit.
It would ensure that the add is always done just before the commit.

On a side note, I am not sure it is such a smart idea to want to make the cvs
plugin so easy to use at any cost.
Either you are developping a plugin for users knowing cvs well, in which case,
it should be easy to do with eclipse everything you can do with cvs, or you are
developping a plugin for users not knowing cvs well, in which case, there are
far too many options for them not to make mistakes every day.

In the company we work for, the cvs plugin is the point that keeps most people
from using eclipse because even if they feel it is simple at first glance, they
are afraid of what eclipse really does. (when branching/tagging branches, using
sticky tags, etc ..)
It might seem silly but the fact that it has been made so easy to use comes as a
major drawback for a lot of people I know ... 

Anyway, you are the commiters, but I think it might be important to have a big
brainstorm about what should really allow the interface (maybe it is already
being done).. Maybe there could be several levels of cvs control (a basic one
with just update/commit/tag kind of the way it is done today, an expert one that
would allow to do some kind of "raw" cvs action on a given file or directory),
maybe there should be the possibility to ask eclipse to show the command line
cvs equivalent of the ongoing operation and ask for confirmation ...

That would allow us for instance to use cvs tag and cvs rtag depending on what
we prefer/want.

I am sorry if I am the bugger here, but I like eclipse much and I would really
like it too be user-friendly for ALL users. Again, I do not want to throw what
has been done to garbage, it remains one of the greatest cvs GUI.
Comment 3 Michael Valenta CLA 2004-09-23 11:06:17 EDT
In regards to your statement about making things too easy, obviously, you 
can't make a tool so easy to use that you can't get anything done. I guess it 
depends on what costs your willing to accept. Our initial goal was to make CVS 
usable for people who had no knowledge of CVS. Therefore, we only supported a 
particular set of workflows. Of course, this made Eclipse CVS usable for some 
and not for others. Only later did we start making Eclipse CVS usable for a 
wider audience (i.e. Eclipse 1.0 and maybe even 2.0 were not usable by people 
with projects on source forge for instance). I'm not sure what you mean by 
people "making mistakes" every day. As I said, we surface very specific CVS 
workflows and if the user sticks to those they can avoid many common mistakes.

Anyway, we have definitely discussed the idea of supporting a "command line" 
like method of running CVS operations in Eclipse. However, given that the 
command line client gives you this already and the sandbox Eclipse creates is 
compatible with the command line there is little incentive to duplicate this. 
Of course, if it were easy to do, we would do it but it would actually be a 
great deal of work.

As for user being afraid of what Eclipse CVS does under the covers, you can 
always enable the CVS console view (on the Team>CVS>Console preference page). 
This will show the output of any command that Eclipse performs. If this 
doesn't help then, as I said, Eclipse is command line compatible so you can 
use whichevenr CVs tool you prefer.
Comment 4 Eclipse Webmaster CLA 2019-09-06 16:16:36 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.