superfluous ChangeSet comment when no changes

[Perry]

When I check in a change set that actually contains no changes, and I have the revert option for unchanged files, it seems superfluous for the Vault client to prompt me for a ChangeSet comment -- does it do anything with it, or does it throw it away?

[lbauer]

If you're getting a prompt, it's probably because your repository options include a requirement for comments on all checkins.

If you try to checkin unmodified files with the revert option, Vault basically does an "undo checkout" and the transaction is not saved in history, so the comment isn't saved either.

You could just undo the checkout and avoid the prompt.

[Perry]

I have a suggestion. Instead of me the human trying to figure out if there are any unchanged files, to determine whether I should do a checkin or do an undo checkout, because it would be dangerous for me to make a mistake (and possibly lose changes), how about the program figure it out for me?

(I have a general philosophy that its better to move reliance from human to program, for tedious and repetitive tasks.

I mean, you just about have this now anyway. The program does figure it out for me (whether files changed or not), but it still prompts me for a ChangeSet description -- I don't understand why it prompts me to think up text, which it is going to throw away. That seems a waste of time for both of us (me and the program), doing the prompt & me filling it in, and then the program throwing that text away.

[lbauer]

True. I'll log it as a feature request for a future release of Vault.

[GregM]

Not knowing anything about how Vault is implemented, I would guess that the prompt for the comment is done before the point where it actually does the checkin, and decides whether to check in or undo the check out.

I know there are at least twice as many development styles as there are people using them, but it seems dangerous to not know exactly what you are checking in. If you don't know whether or not you've made any changes to the files, why are you checking in the files in the first place?

[Perry]

GregM,

Let me answer your question, which is, why am I checking in files?

The answer is, because
(a) I checked them out
(b) using VSS style exclusive checkout
so further development in that project is at a standstill until I check them in. So you can see there could be some natural pressure on me to check them in, as noone else can work in that project until I do.

You also, implicitly I think, asked, why don't I know if I changed anything?

Well, I'd answer in two parts:
(a) Why are you looking to me to answer that, when it is the main purpose of the source control to know that answer authoritatively and better than me myself? (This gets back to the philosophical point I mentioned above, which is that I prefer not to rely on humans to do what I call "monkey work", meaning automatable work that the program could do for them.)
(b) In this particular case, I checked out many directories, to work off-line for a while, and as it happens, none of my changes wound up in this particular directory

[GregM]

Why are you looking to me to answer that, when it is the main purpose of the source control to know that answer authoritatively and better than me myself? (This gets back to the philosophical point I mentioned above, which is that I prefer not to rely on humans to do what I call "monkey work", meaning automatable work that the program could do for them.)
(b) In this particular case, I checked out many directories, to work off-line for a while, and as it happens, none of my changes wound up in this particular directory

Like I said, many different philosophies. I see the main purpose of source control as keeping track of changes, and secondly letting me see what I've changed before I check it in, as a sanity check. If a developer doesn't know what they've changed, and can't tell me off the top of their head why they're checking in something, without having to stop and make something up, I don't want them checking it into source control. Knowing that the changes you made belong in source control, and knowing why you made those changes shouldn't be considered "monkey work". If someone is just checking in files "because someone else needs them", and not because they're finished whatever they're working on, that's just asking for trouble.

[Perry]

Ok, if Vault is meant to enforce the philosophy that every user must review every change before checking it in, then my RFE should be denied (and you may even want to force the user to click through the diff results window).

I've not read all the Vault docs, I'm afraid, so I am not sure what style of development it is meant to enforce.

[Perry]

Perhaps you misunderstood, or confused my case example with another, because you said:

> If someone is just checking in files "because someone else needs them",
> and not because they're finished whatever they're working on, that's just
> asking for trouble.

which is not from the case example I gave.

[Perry]

I have another suggestion.

If Vault is meant only to support small incremental changes, and not systemic changes or large refactorings, you might want to note that on the marketing; we were not aware of any such limitation in its marketing orientation.

But, of course, as I admitted, I have not read through its docs sufficiently to know what type of limitations it is meant to impose upon development.

[jclausius]

Perry:

Vault is designed track changes to files - period. This includes all types of changes made to your files - new / deprecated functionality, refactoring, bug fixes, changes to binary files, etc.

If we do hit some sort of limit, we are usually working to improve this in the next major release - for example your user request about the required comments.


Of course, we're always trying to improve functionality so we can satisfy ALL our users - this includes both you and GregM.

[ericsink]

If Vault is meant only to support small incremental changes, and not systemic changes or large refactorings, you might want to note that on the marketing; we were not aware of any such limitation in its marketing orientation.

Nobody here said that "Vault is meant only to support small incremental changes, and not systemic changes or large refactorings".

You found a situation where we could make an improvement to the usability of Vault. I'm not inclined to make a bigger deal of it than that.

[GregM]

Perry, in case you were confused, I don't work for Source Gear, I'm just a user. I can't make any statements about the intent of vault.

[ericsink]

Perry, in case you were confused, I don't work for Source Gear, I'm just a user. I can't make any statements about the intent of vault.

Ah, yes. Thanks for clarifying that. But just to be clear: We do still appreciate it when users participate in discussions, so thanks for your posts here.

[Perry]

Oh, I have been sick, which makes me get confused easily, and I got confused -- thanks for straightening that out, and thanks for all the feedback in all forums -- thanks to both Vault developers and to others.