[p4] The story of the null delta.

[Oren Shemesh (oshemesh)]

Indeed, after quite a few years of administering Perforce for ~100
users, nobody ever complained about the extra revision that sometimes
gets created with you accidentally submit an un-changed file.

Maybe it is because most users only check-out a file when they actually
want to change it (And not a second sooner), so it never gets to be
checked-out unmidified.
Maybe it is because most users use P4Win and configure it not to submit
unchanged files (At the expense of a small delay when submitting).
Maybe it is because they are so happy with P4 that they forgive such
small issues in advance :-)

Whatever it is - in my opinion, using obliterate simply to remove
unneeded file revisions is a big mistake. Obliterations should be used
with a lot of caution. The damage you might inflict when you
accidentally obliterate the wrong thing (Which is bound to happen if you
do it often enough) is much bigger than the benefit of keeping the CL
clean.

Oren.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of David Weintraub
Sent: Monday, March 26, 2007 8:22 PM
To: dlewis78731 at gmail.com
Cc: Perforce Users
Subject: Re: [p4] The story of the null delta.

I always thought it was strange that Perforce checked in unchanged
files with nary a peep. That is definitely not the behavior of any
other version control system I've worked with.

SCCS, RCS, and ClearCase won't check in unchanged files by default.
These revision control systems all make you "checkout" a file before
editing it. If you "checkout" a file, don't change it, and then
attempt to check it in, you'll get an error. You need a command line
switch to force a check in of an unchanged file.

CVS and Subversion don't normally check in unchanged files by default,
but mainly because there is no checkout. Only files that were changed
are actually checked in.

Perforce's checkout (p4 edit) really isn't a checkout in the sense of
SCCS or RCS since it doesn't lock the file. The whole purpose is to
allow you to put the file in a changelist. And, if you have an
unchanged file in a change list, how would you handle it? Reject the
whole changelist or throw that one file out of a user's changelist
without consulting them? Plus, it would greatly slow down Perforce if
it had to verify each file to see whether or not it was changed before
checking it in the changelist.

In the end, extra versions don't really hurt anything. They don't
change the archive file although it does create another entry in the
database. Maybe a bit frustrating taking the diff between various file
versions and finding out that there are no changes.

--
David Weintraub
qazwart at gmail.com
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user