[p4] Versioned directories and corresponding file modifications

[Biswajit Dash]

Interesting Topic for discussion.

If I will have to choose between 
"Directory versioning" and "ChangeList" I will choose
the later.

"Usage Pattern" is what determines our comfort level
with these two implementations.

The good part in Directory versioning is History of
the file is Uniform.
Whereas in Perforce, we have multiple revision
history, Linked through a Integration records. 

> What happens when you
> rename a#45 to b, does it become b#1 or b#46?  What
> if b already had existed
> and had gone from b#1 to b#75 before being deleted? 
> You'd almost need to
> stick to changelist numbers only.
In this case b#76 Gets created 
But this problem is better than "Evil twins"
( I do have many experience with Evil twins in
clearcase. Though we cam have trigger mechanism to
prevent them, It becomes a performance over head" 

IMO: Directory versioning comes with a Cost whereas
Change list makes things Simple.

Also I think we can discuss further on this Topic To
have a better solution by taking the "Good" aspect of
both of these.

Thanks,
Biswajit.

--- Jeff Grills <jgrills at drivensnow.org> wrote:

> 
> I should confess up front that I typically only
> glance at emails that go on
> about versioned directories.  I'm typically quite
> busy, so I don't spend a
> lot of time reading about things that aren't likely
> to affect me.  I'm not
> sure how I'd go searching the archives for the
> answer to this question
> either, so let me just set the stage and toss the
> question out there.
> 
> When I go refactoring code and changing file names,
> quite often files refer
> to the files I'm renaming.  Sometimes the referring
> files themselves are
> being renamed, but sometimes they're not.  An
> obvious example in the C/C++
> world are source and header file pairs; when I
> rename a pair of them, I may
> have to touch a bunch of other files in order to
> keep the project building.
> If I rename .cpp/.h pair, I'll likely have to change
> the .cpp file to
> include the right .h file, and certainly other
> non-renamed .cpp files may
> need to be changed to get the get to the .h file
> name as well.  I've also
> worked at development houses where one primary C++
> class is stored per .cpp
> source file, and the class name and the file name
> are the expected to be the
> same, so when you touch the class name or the file
> name, you really need to
> touch the other as well.  So when I rename source
> files in Perforce, I
> typically integrate the files to their new names,
> delete the old files, and
> edit (or reopen for edit) those files that I need to
> modify so that when I
> submit that one changelist atomically, everything
> still builds and runs.
> 
> How is that dealt with in a system where directories
> are versioned?
> 
> I could see this situation being potentially much
> cleaner in such a system.
> I'd assume you rename the file by editing the
> directory and changing lines
> to rename the old files to the new files (that's not
> how the user interface
> would expose it, but one could conceptually view it
> that way - a rename
> command is an edit a single line of the directory),
> and then you edit the
> files necessary to fix up the references to other
> files.  This way the
> rename operation doesn't get muddled in with the
> changes necessary to
> support the rename, but you still would want to
> submit all of those changes
> atomically so that your build remains in a valid
> state the whole time.
> 
> In this case, the versioned directories sure do seem
> attractive.  I can
> clearly see some complications that would arise, for
> sure.  The "evil twins"
> case was recently mentioned in an email.  It seems
> like that makes
> incremental file revisions numbers, well, not very
> useful.  What does
> file#10 mean?  Which file are you referring to? 
> What happens when you
> rename a#45 to b, does it become b#1 or b#46?  What
> if b already had existed
> and had gone from b#1 to b#75 before being deleted? 
> You'd almost need to
> stick to changelist numbers only.  I personally
> rarely use revision numbers
> anyway, much preferring changelist numbers because
> they imply the entire
> state of the system at a particular point in time
> instead of just one file,
> so this might not be any great loss.
> 
> Hm. It's certainly something to think about.
> 
> j
> 
> _______________________________________________
> perforce-user mailing list  - 
> perforce-user at perforce.com
>
http://maillist.perforce.com/mailman/listinfo/perforce-user
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com