On Thu, Aug 17, 2006 at 01:35:43PM +0200, Zbynek Winkler wrote:
> So, now I'm leaning very much back towards having branch names that
> are not leaves in the namespace -- because this hierarchical nesting
> is more expressive in this case. Even if it does really confuse
> everyone used to svn/darcs/bzr/hg/..., with their branches as leaf
> URLs :-).
>
> I do not think this is true for hg. You can easily branch into the same
> space. I've just tried something along the lines of
>
> hg init .
> hg clone . subbranch
> echo "Hey" > fff
> hg st
> ? ffff
> hg add ffff
> hg ci
> cd subbranch
> hg pull
>
> Works just fine. I can pull either . or ./subbranch. Unless you meant
> something else?
No, that's what I meant. Thanks for the comment.
What happens if mainline happens to contain a file name "subbranch"?
C:\temp\aaa>hg clone . subbranch
abort: destination 'subbranch' already exists
But it IMHO does not really matter because the actual name of the branch is irrelevant and can be changed any time... it is just a name of a directory...
Does looking at this scheme make you nauseous from the way it violates
the expectation baked into hg's model that a branch location contains
the files in that branch, not other branches?
Not really. Actually I find the concept quite straight forward. When in some directory, hg climbs up to find ".hg" directory with the history data. When descending again it ignores directories containing directory named '.hg'.
It does not really care if something is a branch of something else or not. It is all based on a single assumption that a directory containing '.hg' subdirectory is a working space with associated history data. Hence pulling from any path where appending '/.hg/' to it yields the proper data works.
> Unless anyone has any ideas on a less confusing way to accomplish this
> goal?
>
> Maybe branch renaming could help? When branching of the trunk create a
> leave. Afterwords rename the .roster-no-hash to .roster-no-hash/trunk and
> create another named .roster-no-hash/new-crazy-idea?
Hmm, good point -- branch renaming is already baked into this scheme
anyway. This seems a little elaborate to go through all the time,
though; I worry a lot about defaults because they're what tends to
guide what people end up doing in the common case. A possibility that
no-one thinks of isn't so useful; a possibility that will make users's
lives easier should be nudged towards their awareness...
Agreed it is seems too elaborate...
Zbynek