About IBranchingVC...

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 17.05.07 14:24:26, Matthew Woehlke wrote:
>> How exactly is branch() supposed to work? In perforce, a "tag" (label) 
>> requires the source files to be checked out, while a branch() requires 
>> the destination to be in the view (branch() == copy() except somewhat 
>> more sophisticated). Also there is a "branch" object that would 
>> (should?) be created in this case. Also labels in perforce need a name 
>> (no surprise here).
>> [snip]
>> Options:
>> - perforce doesn't implement IBranchingVC
>> - clarify what branch() and tag() do in a way that is favorable to a 
>> perforce implementation
> 
> Ok, how about this:
> 
> branch() takes either a working copy or remote path and creates a branch
> for that in a target path or with a target name. Or does p4 need a
> mapping here too, i.e. something like
> foo/bar->foo/branch1/bar
> boo->foo/branch1/boo

Actually perforce takes a list of repo paths for a branch spec or label 
spec. Note that there is "a branch spec" which is just a server-side 
object containing the aforementioned path list, and then there is 
"creating a branch" which actually just means copy()+commit(). The 
important part is that branch() requires the target to exist in your 
working copy (noting that in perforce it is permitted to have a working 
copy point to something that does not yet exist). This is one of the 
semantic ugliness's around branch().

>> - drop IBranchingVC altogether; plugins will expose the VCS's native flavor
> 
> Looking at the above you always have to know which VCS you deal with, so
> I guess this is the option to go. VCS' can provide their own interface
> if they want to allow scripted branch creation. I do think we could
> provide showBranch() and showTag() for example in the IRepositoryVC, how
> does that sound?

Right, agreed. I guess showBranch/showTag is OK (although I would 
question the usefulness at this point, you can't automate them so what 
are you really gaining?). I'm not really against it, but what is the 
benefit?

OTOH, could CVS and svn share a more sane IBranchingVC (without making 
the methods ugly as in my reply to Matt)?

BTW, in both perforce and svn, there is no mandated logic for where a 
branch must go, i.e. it is legal to create a branch of //foo -> //bar, 
where // is the repository root (i.e. just because svn /encourages/ 
//trunk, //branches and //tags doesn't mean you *must* have any of them. 
See Vim (until recently, anyway) for a real-world example. (Our perforce 
repository is totally unique in this respect.)

>> NOTE: Shouldn't copy(), etc in IRepositoryVC take lists?
> 
> svn doesn't allow that,

It doesn't? Ok, I was misremembering; shows what I get for not looking 
before I open my big mouth ;-).

I guess in that case branch() really isn't supported either, at least 
not as far as being able to use a VcsMapping... which means that svn's 
branch() is just copy().

Hmm... this is probably the number one reason why perforce's branch() 
*must* be in IPerforceVC*... it *must* support multiple paths at once.

(* though not necessarily /exclusively/ in IPerforceVC)

> does perforce allow to copy individual files in
> 1 commit to a directory?

IBasicVC::copy() does (that shouldn't be surprising :-)). Perforce does 
not support repo-side operations - i.e. IRepositoryVC - at all, so that 
side of the question is moot.

-- 
Matthew
/bin/sh -- still Bourne on Solaris (and still not POSIX compliant)