[p4] I cut down the tree while everyone stood on the branches.

[Smith, Jeff]

That would actually be very bad and would violate a major piece of the
Perforce philosophy.  When a changelist is submitted, all of the
intended actions are committed or none of them are.  Atomic commits of
intention are one of the things Perforce does very well.  I think
sacrificing that would cause more harm than good.

Jeff

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Darryl G.
Wright
Sent: Thursday, June 15, 2006 12:34 PM
To: Weintraub, David
Cc: perforce-user at perforce.com
Subject: Re: [p4] I cut down the tree while everyone stood on the
branches.


Again, thanks for the responses.

Ideally, I would have expected to have the checked out files simply
remain 
even after the delete. Then when the last person checks in, Perforce
would 
decrement some sort of usage counter so it knows when to perform the
next 
series of actions (ie. the history of what's happened to the file since
it 
was checked out). Of course, that's all easy to say when you're not a 
Perforce developer. I am sure there are probably fundamental reasons why

that wouldn't work based on it's current design.

Thanks,
Darryl


Weintraub, David wrote:
>> It sounds crazy that it would let me delete a folder while people
> still had files checked out.
> 
> It's a question of how you want to look at the issue. In RCS and SCCS,

> you had file locking. Once someone checked out a file, no one else 
> could edit it. It kept the problems of merging to a minimum. However, 
> that lead to a lot of people waiting around for someone to finish with

> a file before they could do any work. Modern version control systems 
> like Perforce have taken the approach that stopping work is a bad 
> thing. Yes, merging is sloppy and hard, but it's worth forcing the 
> merge over stopping development.
> 
> The same could be said for moving and renaming files. Should 
> restructuring of the source code be held up because one person has a 
> file checked out? Most version control systems do allow for 
> restructuring.
> 
> I think one of Perforce's problems with this issue is the fact there 
> really isn't a rename/move command. You basically "branch" the file to

> another name or directory, then you delete the old copy. This makes it

> hard to track these changes taking place. I'm not 100% sure how 
> ClearCase handles this particular issue because of the way we used it.

> Users worked on independent branches, and not the trunk.
> 
> However, when those users merged their work onto the trunk, ClearCase 
> was able to figure out the new names and locations. It wasn't 
> painless, but it was much easier to handle than with Perforce. In 
> Perforce, you have to conduct an investigation on what happened. In 
> ClearCase, you had to merge your changes into the renamed files, but 
> at least ClearCase let you know exactly what happened.
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Darryl G. 
> Wright
> Sent: Thursday, June 15, 2006 8:47 AM
> To: perforce-user at perforce.com
> Subject: [p4] I cut down the tree while everyone stood on the 
> branches.
> 
> Thanks for your answers yesterday regarding my rename issue. I 
> successfully renamed the entire folder which resulted in a integration

> followed by a delete of the old folder. As it turns out, several users

> still had files checked out in the old folder under the old name. Are 
> they totally fubar'ed now? Is there any way they can still check their

> changes back in? It sounds crazy that it would let me delete a folder 
> while people still had files checked out. But crazier still would be 
> if it didn't allow them to check them back in.
> 
> Thanks.
> 
> Darryl
> 
> --
> Darryl G. Wright
> Technical Lead
> HB Studios
> 
> http://www.hb-studios.com 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 

-- 
Darryl G. Wright
Technical Lead
HB Studios

http://www.hb-studios.com
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user