| Re: [stellation-res] new drop of unit tests |
On Fri, Aug 02, 2002 at 02:30:25PM -0400, Mark C. Chu-Carroll wrote: > On Friday 02 August 2002 11:52 am, Florin Iucha wrote: > > If > > * revision x has a file called file1 > > * in revision x+1 the file is renamed to file2 > > * revision x is checked out in a workspace > > * revision x+1 is checked out in a workspace > > should the workspace contain two files? > > At the moment, it will. As for whether it should, that's open to debate. > > One underlying principle that we've had in Stellation is that the > command line tool really shouldn't ask questions. A command > should do the most reasonable, expected action, so long as it's > non-damaging. For damaging commands (ie, commands where executing > the command will damage an existing workspace and possibly > destroy some unchecked-in changes), the command should abort > unless the programmer specifically told it to go ahead, by using "--force". > > We've adopted that principle because of our experience with PRCS, > which asks questions about *everything*, which is very annoying, > and in fact, frequently leads to errors, because there's just too much > stuff being asked. When you ask too many questions, people stop reading > them, and just take the default, which is right 99 times out of 100. But > by asking all those questions, you make it *harder* to catch that 1 time > in 100 when the default is wrong. You've automatically hit the return > key to accept the default before you noticed that *this* question > was different from the others, and now, you're screwed. > > So... for that case of checking out into an existing workspace, > the default is to refuse to checkout into an existing workspace > unless you force. And the force won't delete what it views as non-project > files in the workspace - we don't delete stuff unless you explicitly ask us > to. If you want to get rid of old files in the directory, and get a perfect > clean checkout image in an existing workspace, you do a "svc clean" after the > checkout. > > This is one of the places where I'm not sure if the default is right. I tend > to view a workspace as something completely controlled by the SCM > system. When you do a checkout, I don't particularly like the lingering > stuff hanging around. My preference would be to refuse to checkout > into an existing workspace without force, and to have force'd checkouts > automatically do a clean. The catch is that that deletes any files > in the space that haven't been added yet. That's what you get by using --force. We could do like linux raid utilities do: a --force aborts the operation and displays a message telling you to go read the fine manual. In the manual one will find the --really-force option. > > My take is that when I do a checkout I get an exact image of the project > > at revision X. If a working file is about to be deleted, I should be > > propmted unless I specify "--force". So we agree... You say it should fail, I say it should prompt. I am ok either way because it will not destroy my data. Just make sure to put an explanation as to why it failed. I will add a call to "svc clean" after checkouts. florin -- "If it's not broken, let's fix it till it is." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Attachment:
pgph9eEexYtTh.pgp
Description: PGP signature