[p4] Versioned directories and corresponding file modifications

[Biswajit Dash]

Hi Jeff,
Do you mean to say, 
Lets not have File revisions at all ?
and we will only use changelist numbers ?
Thanks,
Biswajit.



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

> 
> I thought I was reasonably clear, but I did ramble
> on for a bit.  I don't
> think it's a choice between changelists and
> versioned directories, instead
> I'm saying you'd have to do something about
> incrementing file revisions
> (specified like a#1 and a#2), like give them up and
> use ONLY changelist
> numbers to specify a file's revision (specified like
> a at 6534 and a at 7045).
> 
> I certainly wouldn't want to give up changelists
> (especially atomic) either.
> 
> j
> 
> -----Original Message-----
> From: Biswajit Dash [mailto:biswajitind at yahoo.com] 
> Sent: Friday, June 16, 2006 1:05 AM
> To: Jeff Grills; perforce-user at perforce.com
> Subject: Re: [p4] Versioned directories and
> corresponding file modifications
> 
> 
> 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 
> 
> 
> 


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