[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: post-commit hook questions

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-10-15 02:36:30 CEST

Noel Yap wrote:

>I think I see. If I want it to be inside the
>transaction, it already is, but do you know if it can
>deadlock itself? If I don't want it outside the
>transaction, I can fork off another process. Is that
>right?
>
Why don't you try? I don't know if you get a deadlock or not (I guess
not); but it should take you about 10 minutes to write a simple script
that'll answer your question.

>I think differentiating between branches and tags is
>aside from enforcing a repository layout since, in
>essence, branches and tags can be thought of as
>different types of repository elements.
>
The're not. Yes, I know ClearCase has different namespaces for them; but
to Subversion, they're just directories.

>If, for example, as someone had suggested earlier, a
>"svn ln" command were created that can create hard
>links, then tags could be created using "svn ln" while
>branches could be created using "svn cp". Not only
>would the hard link be implicitly read only, but one
>would also be able to tell the difference between
>branches and tags.
>
I'd have to see a much more detailed and thought-out spec for the
semantics of "svn ln" before I can comment on that.

>>What are you trying to do, anyway?
>>
>>
>
>I'm trying to create a ClearCase-like repo structure
>like the following:
>/project
> /main
> /HEAD
> /0
> /1
> /LABEL -> ./1
> /branch
> /HEAD
> /0
>
>where both everything is a directory except
>/project/main/branch/HEAD which is a branch, and 0, 1,
>and LABEL are all tags. Now that I'm answering your
>question, I just realized that I was thinking that
>both main and branch were branches. I'll have to
>reassess my thoughts.
>
I think you have to rethink your layout a bit. How about this:

    /project
      /main
        /HEAD
        /_BR_
          /dev
            /HEAD
            /_BR_
            /_LB_
            /_VN_
        /_LB_
          /LATEST
        /_VN_
          /0
          /1

That keeps branches and labels nicely separate, you get a hierarchical
namespace of branhes, and you can tell the difference between a branch
and a label simply by looking at the path. So, what ClearCase would call

    foo.c@@/main/dev/LATEST

would in this schema become

    /project/main/_BR_/dev/_LB_/LATEST/foo.c

and

    foo.c@@/main/1

would map to

    /project/main/_VN_/1

Note that the ClearCase version numbers are in a different namespace
than labels and branches, and that for your purpose they behave like
labels, not like branches. Also, you don't need top-level namespaces,
because the main branch is required anyway, and labels are always
applied within branches.

I'm not sure how you intend to apply the same label to different
branches of the same object, the way ClearCase does. If I were you, I'd
impose some restrictions on the CC-to-SVN mapping in this respect; if
you do that, then you only need a single global namespace for labels.

>Essentially, when main and branch are created, I'd
>like the post-commit hook to create the HEAD directory
>and branch, respectively, and the 0 "branch" revision
>tag. Upon checkin to HEAD, successive "branch"
>revision tags should be created. Nothing need be done
>upon creation of LABEL. The problem is that both
>LABEL and branch look alike to Subversion but they
>should be treated differently by the post-commit hook.
>
Huh, why do you want to do that in a post-commit hook? Instead, you
should use a start-commit hook, then you can examine and modify the
transaction _before_ it's committed, and all your problems go away. Of
course, to modify the transaction, you'd have to use either the SWIG
bindings, or write a C program that links with the libsvn_fs library.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 02:37:12 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.