Re: philosophical question about frequent saving of files
Ivan Soleimanipour <[email protected]>
| Newsgroups | gmane.comp.java.netbeans.user-interface |
|---|---|
| Message-ID | <[email protected]> |
> From: Tor Norbye <[email protected]> > To: [email protected] > Subject: Re: [nbui] philosophical question about frequent saving of files > > On Aug 26, 2005, at 1:11 PM, Ivan Soleimanipour wrote: > > > With this suggestion of yours tor you'd have the immediate > > undo/redo, your save scheme and the VCS based save scheme. > > > > Just more stuff to manage, terminology etc. Do > > we really need more technological solutions? > > > > In any case, isn't it the case that with SCCS/teamware (as opposed to > > CVS) "experiment" gmgmt is easir because of the local repository? > > It may be easier, but I don't want my file revisions individually > checked in. Everytime I check in a change, I provide an explanation/ > commit message for that change. This is inherently different than the > undo history. I always do a diff of what I'm about to check in too > as a final step. If I want to make an "experiment", I check in my current work, check out fresh copies, do my experiment. If it fails I throw out my sccs edits. > I don't remember the details, but one of the important things you do > in this window is diff one version wrt. another. So if for example > something you were working on suddenly stopped working, you can diff > this version with previous versions over the last couple of hours and > notice that perhaps you accidentally deleted a line or something. I have to ask ... do you actually have any self-awareness while you're programming? I mean in the pick-your-favorite-easter-philosophy sense. > It would be nice too if operations which cause a Save on a file could > annotate the version history. E.g. in addition to normal "Ctrl-S" > revisions for when you've saved the file yourself, if you hit the Fix > & Continue button the revision would be labeled the Fix & Continue > rev, if you did a refactoring, the revision would be annotated > "Refactor: Rename Foo to Bar", etc. But now I'm dreaming. So you'll end up with a lot of "saved for build on <date-timetamps>". Sounds like a recipe for information overload :-) What I"m saying, unlike what Mr. Hollingsworth read, is wouldn't it be possible to factor the three systems you're now proposing undo/redo, short-term saves and sccs saves into something that uses only two mechanisms? Otherwise it's going in the direction of PERLs a curlique per itch. My favorite example here is CVS. where you have wholesale repository branching and the lore associated with merging them, standard branchings with the lore associated with them! and regular programmer checkouts, While under teamware all three activities are captured by one concept.