Re: [stellation-res] new drop of unit tests

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Friday 02 August 2002 11:52 am, Florin Iucha wrote:
> Major changes:
>    - support for versioned directories. Not fully tested, but most
>      code is there.
>    - one new test, that renames the file (*)
>
> Minor changes:
>    - some outline for merge tests
>
> No changes:
>    - Ringo suggestion for replacing StringTokenizer hasn't got in yet.
>      will go in the next drop.
>
> (*) Unfortunately the test is failing as is. I have a feeling this is a
> bug but I am asking before shooting (in Bugzilla):
>
>    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.

	-Mark


>
> 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".
>
> Thoughts?
>
> florin

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx