You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Noel Yap <ya...@yahoo.com> on 2002/10/15 11:00:18 UTC
"svn branch" and "svn label"
In another thread, I was thinking of wrapping the svn
client to create "branch" and "label" in which the
"branch" command, after performing a "svn mkdir" would
also create a HEAD branch (or directory if the branch
is main) and a 0 branch revision tag.
My thoughts evolved into making these svn client
commands but instead of having "branch" perform stuff
others probably don't want, both "branch" and "label"
would set a property, say "svn:type" (if it's already
taken, we can use another tag), that would signify its
type.
The "svn:type" tag can also be set for normal files
and directories.
The next step (for my hooks to work) would then be to
have the svn prop commands work with a URL so that the
commit hooks can use them. I'll start looking into
what needs to be done to make this happen since I
think I'll need this in any case.
Comments? Ideas? Preferences?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> I'd just like to further understand why everyone is
> against the following:
> 1. Adding "svn branch" and "svn label" (which, BTW, I
> seem to recall reading about in the doc).
We decided to go the simpler route, interface-wise, and just have
'svn cp'. (Some doc must be out-of-date.)
> 2. Adding "svn:type" to indicate element types.
Because it's added complexity that, in some people's opinion, doesn't
bring enough benefit to be worth it.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Garrett Rooney <ro...@electricjellyfish.net>
wrote:
> Noel Yap wrote:
>
> > I'd just like to further understand why everyone
> is
> > against the following:
> > 1. Adding "svn branch" and "svn label" (which,
> BTW, I
> > seem to recall reading about in the doc).
>
> well, i don't think you'll find it anywhere in the
> docs...
Ahh, here it is. From the Subversion Design document
under Branching and Tagging:
Note that from the user's point of view, there are
still separate branch and tag commands, with the
latter initialiszing the clone as read-only ...
> what do you think such a command would do? svn
> doesn't have any built
> in idea of what a 'branch' or a 'label' is. they're
> both just
> directories, so you create them with 'copy'.
Right, the file system doesn't know the difference.
The proposal doesn't intend to change that in any way.
> > 2. Adding "svn:type" to indicate element types.
>
> what exactly do you mean by 'element type'?
An element type would be one of directory, file,
branch, tag, or special types (eg pipe, ...) if
support is later added for them.
I think the element type is as much metadata as other
metadata.
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Noel Yap wrote:
> I'd just like to further understand why everyone is
> against the following:
> 1. Adding "svn branch" and "svn label" (which, BTW, I
> seem to recall reading about in the doc).
well, i don't think you'll find it anywhere in the docs...
what do you think such a command would do? svn doesn't have any built
in idea of what a 'branch' or a 'label' is. they're both just
directories, so you create them with 'copy'.
> 2. Adding "svn:type" to indicate element types.
what exactly do you mean by 'element type'?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Noel Yap <ya...@yahoo.com> writes:
> > Comments? Ideas? Preferences?
>
> Yes -- a preference to not do this :-).
That's two so far :-) I'll probably just wrap the
Subversion client then to mark the elements with
metadata indicating their types.
> I'm still not clear on the problem you're trying to
> solve. What's not
> working about the current model? What was the
> problem you encountered
> (and I do mean "encountered", not "anticipated")?
I'm encountering the problem trying to create a hook
that'll treat branches differently from tags.
Actually, I keep confusing myself (as may have been
evident ;-). Yeah, now that I'm rethinking this some
more, what I really want to do is differentiate
between directories and tags. For example:
/project # directory
/main # directory
/HEAD # directory
/0 # tag
/LABEL # tag
/branch # directory
/HEAD # branch
/0 # tag
/branch is really a directory and /LABEL is a tag
(which, to Subversion, is really a directory, too). I
want my hooks to create HEAD (which would either be a
directory or a branch) and 0 for directories (with
certain exceptions) and do nothing for tags.
> From what I've read, it looks like you could
> accomplish what you need
> with custom hooks, with no need to change the
> Subversion client. But
> perhaps I'm misunderstanding your problem. If you
> want people not to
> commit to tags, just protect the tag areas from all
> changes except
> adds.
One of the things I do want to do is protect the tags.
With the layout I'd like, the hooks would have to be
able to differentiate among directories, branches, and
tags.
> > Isn't it also a feature not to impose any
> particular
> > directory structure? If someone had wanted to
> treat
> > branches differently from tags (eg for
> permissioning),
> > currently, since Subversion can't tell the
> difference,
> > the only recourse is to have some convention
> within
> > the repository. The typical proposal is to
> separate
> > the namespace of branches from that of tags. Not
> > imposing separate namespaces would make Subversion
> > more flexible.
>
> Noel, it sounds like you're trying to duplicate an
> experience you had
> with another version control system. We're never
> going to be able to
> satisfy that. Just try it the Subversion Way, see
> how you like
> it :-)...
I'm stubborn :-). I really think it's not a stretch
for Subversion to support the above hierarchy. Since
noone is on my side on this and, in fact, some are
against the idea, I'll just wrap Subversion to supply
the info the hooks need.
I'd just like to further understand why everyone is
against the following:
1. Adding "svn branch" and "svn label" (which, BTW, I
seem to recall reading about in the doc).
2. Adding "svn:type" to indicate element types.
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> Comments? Ideas? Preferences?
Yes -- a preference to not do this :-).
I'm still not clear on the problem you're trying to solve. What's not
working about the current model? What was the problem you encountered
(and I do mean "encountered", not "anticipated")?
Re: "svn branch" and "svn label"
Posted by Ben Collins-Sussman <su...@collab.net>.
Brian Denny <br...@briandenny.net> writes:
> doesn't the "global revision number per commit" feature
> make (non-branch) tags kind of unnecessary/redundant anyway?
>
> % cat version_history.txt
> beta72 2345
> beta73 2976
> ...
> % svn up `grep beta72 version_history.txt | awk '{ print $2 }'`
Sure... as long as you keep a nice CHANGES-type file, which subversion
itself does.
The fact that we have a /tags/ area in our own repository is simply
showing off that it can be done. I don't think we actually use them. :-)
But remember also that tags can be more granular, just like branches.
You might want to tag some small subdirectory of a project, and that's
the kind of thing that might not be worth recording in a CHANGES file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: pre-commit hooks modifying transaction (Was: "svn branch" and "svn label")
Posted by Noel Yap <ya...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> > Or, would the problem be that the working
> directory
> > thinks it has checked in say, revision 5, when, in
> > fact, the real revision 5 has other stuff that was
> > tacked on by the pre-commit hook?
>
> Right, that's the problem.
It just occurred to me that what I had in mind will
not modify anything that the user will have checked
out.
For example, if the user were working in
/project/main/HEAD and checks in for the first time as
revision 5, stuff that the hooks will modify will
include:
/project/main # property will be modified
/project/main/1 # cp of /project/main/HEAD -r 5
The other stuff the hooks will do don't involve
working directories since they'll act on cp and mkdir
commands with URL arguments.
Can anyone think of anything else that may be
dangerous when modifying transactions from within
pre-commit hooks?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> Wouldn't this happen with post-commit hooks as well?
No, the post-commit can't modify a revision that's already been
committed.
> Or, would the problem be that the working directory
> thinks it has checked in say, revision 5, when, in
> fact, the real revision 5 has other stuff that was
> tacked on by the pre-commit hook?
Right, that's the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> > > If a
> > > pre-commit hook tweaks a pending transaction, we
> > > risk working copies
> > > falling out of sync!
> >
> > Wouldn't this happen with post-commit hooks as well?
>
> No. The client commits revision 5, and revision 5 really looks the
> way the client thinks it should. It just so happens that the
> post-commit hook *also* creates a new revision 6.
Don't rely on the post-commit hook creating a revision one greater
than the client commit. Nothing prevents another client getting in
between the commit and the post-commit hook. So if the commit creates
a new file, say, then that file may get deleted before the post-commit
hook runs.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Ben Collins-Sussman <su...@collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> --- Ben Collins-Sussman <su...@collab.net> wrote:
> > But regardless, this brings a dangerous situation to
> > light. If a
> > pre-commit hook tweaks a pending transaction, we
> > risk working copies
> > falling out of sync! (Unless some part of the tree
> > is tweaked that
> > the user doesn't have checked out.) Perhaps we
> > should discourage/warn
> > against this situation in our docs, or in the
> > pre-commit-hook template
> > itself.
>
> Wouldn't this happen with post-commit hooks as well?
No. The client commits revision 5, and revision 5 really looks the
way the client thinks it should. It just so happens that the
post-commit hook *also* creates a new revision 6.
> Or, would the problem be that the working directory
> thinks it has checked in say, revision 5, when, in
> fact, the real revision 5 has other stuff that was
> tacked on by the pre-commit hook?
Yes, that's the danger to avoid.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Ben Collins-Sussman <su...@collab.net> wrote:
> But regardless, this brings a dangerous situation to
> light. If a
> pre-commit hook tweaks a pending transaction, we
> risk working copies
> falling out of sync! (Unless some part of the tree
> is tweaked that
> the user doesn't have checked out.) Perhaps we
> should discourage/warn
> against this situation in our docs, or in the
> pre-commit-hook template
> itself.
Wouldn't this happen with post-commit hooks as well?
Or, would the problem be that the working directory
thinks it has checked in say, revision 5, when, in
fact, the real revision 5 has other stuff that was
tacked on by the pre-commit hook?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
> > > Why can't a hook use a working copy?
> >
> > Or why can't a hook just use python libsvn_fs bindings to directly
> > modify a transaction-under-consideration?
>
> He was talking about post-commit, I think. No more txn at that point.
? I thought brane and others had pointed out that he wants to tweak
the transaciton in the pre-commit hook... to prevent infinite commit
loops, creation of new revisions. Noel himself was hoping that the
post-commit would be operating on the the same transaction, which is
why brane pointed him towards the pre-commit hook...
But regardless, this brings a dangerous situation to light. If a
pre-commit hook tweaks a pending transaction, we risk working copies
falling out of sync! (Unless some part of the tree is tweaked that
the user doesn't have checked out.) Perhaps we should discourage/warn
against this situation in our docs, or in the pre-commit-hook template
itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Modifying the txn before commit sounds like very bad
> mojo to me. You
> can end up committing something other than what the
> working copy
> thinks it's committed -- so the working copy and the
> repository will
> get out of sync, and not know it.
Right... Another duplicated CVS feature? :-)
I'll go back to using a post-commit script, using the
API when I need atomic operations.
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> Someone had mentioned possibly using start- or
> pre-commit to modify the transaction. If this is
> possible, it would certainly resolve some of the other
> problems I expect to encounter. OTOH, it would
> require a steeper learning curve on my part.
Modifying the txn before commit sounds like very bad mojo to me. You
can end up committing something other than what the working copy
thinks it's committed -- so the working copy and the repository will
get out of sync, and not know it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
> > > Why can't a hook use a working copy?
> >
> > Or why can't a hook just use python libsvn_fs
> bindings to directly
> > modify a transaction-under-consideration?
>
> He was talking about post-commit, I think. No more
> txn at that point.
I'm currently thinking of using post-commit since I
understand the CLI better than the API.
Someone had mentioned possibly using start- or
pre-commit to modify the transaction. If this is
possible, it would certainly resolve some of the other
problems I expect to encounter. OTOH, it would
require a steeper learning curve on my part.
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > Why can't a hook use a working copy?
>
> Or why can't a hook just use python libsvn_fs bindings to directly
> modify a transaction-under-consideration?
He was talking about post-commit, I think. No more txn at that point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Noel Yap <ya...@yahoo.com> writes:
> > In fact, I think the largest (and only) change that
> > needs to be done is to allow the svn prop commands to
> > work without a working directory so that hooks may be
> > able to use them. Once this is done, the client (and
> > even other hooks) can communicate more info (eg
> > element type) to the hooks.
>
> Why can't a hook use a working copy?
Or why can't a hook just use python libsvn_fs bindings to directly
modify a transaction-under-consideration?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Why can't a hook use a working copy?
I suppose it can. OTOH, doing so would require one to
be updated before being acted on, which'll delay hook
processing some and take up disk space that can
otherwise be used for other things.
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> In fact, I think the largest (and only) change that
> needs to be done is to allow the svn prop commands to
> work without a working directory so that hooks may be
> able to use them. Once this is done, the client (and
> even other hooks) can communicate more info (eg
> element type) to the hooks.
Why can't a hook use a working copy?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Brian Denny <br...@briandenny.net> wrote:
> > Noel Yap <ya...@yahoo.com> writes:
> > > How is tag protection being done now?
> >
> > By not committing a second time under tag
> directories :-).
>
> doesn't the "global revision number per commit"
> feature
> make (non-branch) tags kind of unnecessary/redundant
> anyway?
What's in a name? A symbolic name holds more means
more to humans than revision numbers even though it
may not hold more information.
> Noel: i understand that you want to be able to have
> unmodifiable tags
> and modifiable branches. But i'm still not clear on
> why you need a
> particular directory structure. Is there a reason,
> other than the desire
> to prevent commits on tags?
It's purely religious ;-) The way ClearCase lays out
the repository just makes more sense to me. I
understand that it may be a little more difficult to
get what I want. OTOH, I don't think I need to break
Subversion to do it.
In fact, I think the largest (and only) change that
needs to be done is to allow the svn prop commands to
work without a working directory so that hooks may be
able to use them. Once this is done, the client (and
even other hooks) can communicate more info (eg
element type) to the hooks.
Being able to do "svn branch" and "svn label" would be
nice to have, but I can do that with client wrappers.
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Brian Denny <br...@briandenny.net>.
> Noel Yap <ya...@yahoo.com> writes:
> > How is tag protection being done now?
>
> By not committing a second time under tag directories :-).
doesn't the "global revision number per commit" feature
make (non-branch) tags kind of unnecessary/redundant anyway?
% cat version_history.txt
beta72 2345
beta73 2976
...
% svn up `grep beta72 version_history.txt | awk '{ print $2 }'`
Noel: i understand that you want to be able to have unmodifiable tags
and modifiable branches. But i'm still not clear on why you need a
particular directory structure. Is there a reason, other than the desire
to prevent commits on tags?
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Noel Yap <ya...@yahoo.com> writes:
> How is tag protection being done now?
By not committing a second time under tag directories :-).
That is, there is no protection, beyond peer-reviewed commits. We
could *easily* implement automated protection in the pre-commit hook,
but haven't bothered, since it's trivial to revert a mistaken commit
to a tag. I don't think we've had to do even that, though.
(This is why I distinguished between anticipating a problem and
actually encountering it, in my previous mail.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Philip Martin <ph...@codematters.co.uk> wrote:
> Noel Yap <ya...@yahoo.com> writes:
>
> > I think I was unclear on what I had wanted to do.
> The
> > "svn:type" would be set only on the element (ie
> branch
> > or tag) being created. The operation would still
> be
> > O(1) (unless I'm misundestanding properties).
> >
> > IOW, "svn branch" would do the "svn cp", then "svn
> > propset". "svn label" would do the same thing
> with a
> > different value for "svn:type".
>
> svn tag http://foo.com/repo/trunk
> http://foo.com/repo/immutable
> svn mkdir http://foo.com/repo/immutable/foo/bar/baz
>
> If you don't set the "tag" property on
> immutable/foo/bar how are you
> going to detect this attempt to change it?
I hadn't considered this before.
Considering it now, I would have the hook check each
of the directories and parent directories being
changed.
How is tag protection being done now?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Philip Martin <ph...@codematters.co.uk>.
Noel Yap <ya...@yahoo.com> writes:
> I think I was unclear on what I had wanted to do. The
> "svn:type" would be set only on the element (ie branch
> or tag) being created. The operation would still be
> O(1) (unless I'm misundestanding properties).
>
> IOW, "svn branch" would do the "svn cp", then "svn
> propset". "svn label" would do the same thing with a
> different value for "svn:type".
svn tag http://foo.com/repo/trunk http://foo.com/repo/immutable
svn mkdir http://foo.com/repo/immutable/foo/bar/baz
If you don't set the "tag" property on immutable/foo/bar how are you
going to detect this attempt to change it?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Noel Yap <ya...@yahoo.com>.
--- Philip Martin <ph...@codematters.co.uk> wrote:
> Noel Yap <ya...@yahoo.com> writes:
>
> > My thoughts evolved into making these svn client
> > commands but instead of having "branch" perform
> stuff
> > others probably don't want, both "branch" and
> "label"
> > would set a property, say "svn:type" (if it's
> already
> > taken, we can use another tag), that would signify
> its
> > type.
>
> Looks like a non-starter. Consider
>
> $ svn copy http://some.host/repo/trunk
> http://some.host/repo/branches/xxx
>
> this is fast, it's an O(1) operation. If you want
> to set a propery on
> every file and directory you make it much slower, it
> becomes an O(N)
> operation. If you only set the property on a single
> directory,
> branches/xxx, what do you do when someone access a
> directory below
> that?
I think I was unclear on what I had wanted to do. The
"svn:type" would be set only on the element (ie branch
or tag) being created. The operation would still be
O(1) (unless I'm misundestanding properties).
IOW, "svn branch" would do the "svn cp", then "svn
propset". "svn label" would do the same thing with a
different value for "svn:type".
> Subversion has been designed not to distinguish
> between "tags" and
> "branches", it's a feature. Fast copies, like the
> one above, are
> another designed feature. You have a lot of work to
> do if you want to
> change this.
Isn't it also a feature not to impose any particular
directory structure? If someone had wanted to treat
branches differently from tags (eg for permissioning),
currently, since Subversion can't tell the difference,
the only recourse is to have some convention within
the repository. The typical proposal is to separate
the namespace of branches from that of tags. Not
imposing separate namespaces would make Subversion
more flexible.
In any case, keeping track of the type doesn't break
the feature you speak of since Subversion will still
not distinguish between the two. OTOH, it would allow
hooks to distinguish them.
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn branch" and "svn label"
Posted by Philip Martin <ph...@codematters.co.uk>.
Noel Yap <ya...@yahoo.com> writes:
> My thoughts evolved into making these svn client
> commands but instead of having "branch" perform stuff
> others probably don't want, both "branch" and "label"
> would set a property, say "svn:type" (if it's already
> taken, we can use another tag), that would signify its
> type.
Looks like a non-starter. Consider
$ svn copy http://some.host/repo/trunk http://some.host/repo/branches/xxx
this is fast, it's an O(1) operation. If you want to set a propery on
every file and directory you make it much slower, it becomes an O(N)
operation. If you only set the property on a single directory,
branches/xxx, what do you do when someone access a directory below
that?
Subversion has been designed not to distinguish between "tags" and
"branches", it's a feature. Fast copies, like the one above, are
another designed feature. You have a lot of work to do if you want to
change this.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org