Re: Tags - Symbolic names instead of Directory copy?
Guten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think I’m working on ^trunk@HEAD, but I’m not.Commit does not send changes the “tagged” branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. I may be misunderstanding you but I think this is wrong. Commits of course always go to the directory you checked out, in your case tags/TRUNK-STABLE. If you wanted to work on trunk than I don't know why you checked out tags/TRUNK-STABLE at all? And what's the difference to branches? If you check out branches/someFeature your committs wil always go to branches/someFeature and not branches/branchWhichSomeFeatureBasedOn or trunk or whatever. There's no difference between branches and tags, that's what the last thread was about. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If you wouldn't protect your tags you would get the updates you were missing before. What do you really want, immutable tags or not? Due to those unfortunate semantics, we’ve do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don’t have symbolic names, but we do get the right semantics. branch@revision-semantics would perfectly well work with immutable tags, the problem is that you expect updates and commits for some reason. Yes, I know I’m stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, Why would you want to checkout immutable tags at all? And how do you work with non immutable branches? Why are your developers able to switch from non immutable branches, but not from immutable or non immutable, whatever you like, tags? That sounds a bit weird to me, but I may simply didn't understand your point. but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can’t implement proper hook scripts on our replicated repos.) Does this mean that the problem with invalid hook scripts denying commit access to tags which you mentioned earlier doesn't exist and you are able to commit to tags and getting updates, which you mentioned as missing before and all that stuff? :-) I'm a bit confused... So, am not saying there is anything fundamentally wrong with how “tags” work now. Of course it's not as they work like branches and branches seem to work for you. They just don’t fit our desired semantics, I didn't understand the semantics you want from your description, sorry. so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. But you could simply use tags/TRUNK-STABLE@someRev or wouldn't need @someRev at all if your tags are immutable after creation. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55
Re: Tags - Symbolic names instead of Directory copy?
From: Thorsten Schöning tschoen...@am-soft.de To: users@subversion.apache.org Sent: Thursday, May 23, 2013 2:49 AM Subject: Re: Tags - Symbolic names instead of Directory copy? G uten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think he's thinking of CVS style tags, which are mutable in that you can modify which version of different files have the tag. So everyone works on HEAD and a STABLE tag progresses across it as developers decide different ports are stable. However, as you've mentioned and was more at length discusses elsewhere that's simply not have SVN works. A similar kind of workflow for SVN would be: Main work: /trunk Trunk Stable tag or branch: /tags/trunk-stable or /branches/trunk-stable Do work in /trunk, as things are declared stable merge to /branches/trunk-stable. While I have in the past been able to sympathize with people looking for CVS-style tags (and still do to some extent), I think Subversion style Tags are far more superior primarily from the fact that you can track any changes that are happening to the tag, which you could not do with CVS. Ben
RE: Tags - Symbolic names instead of Directory copy?
From: BRM [mailto:bm_witn...@yahoo.com] From: Thorsten Schöning tschoen...@am-soft.de To: users@subversion.apache.org Sent: Thursday, May 23, 2013 2:49 AM Subject: Re: Tags - Symbolic names instead of Directory copy? G uten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think he's thinking of CVS style tags, which are mutable in that you can modify which version of different files have the tag. So everyone works on HEAD and a STABLE tag progresses across it as developers decide different ports are stable. My example was a poor choice, as I prefer non-mutable tags, but there are certainly use-cases for mutable and non-mutable. There are certainly examples from other versioning tools. Baselines concept in ClearCase, that can be defined then locked. But those get too complex very fast. I really prefer the kind of simplicity in Svn. However, as you've mentioned and was more at length discusses elsewhere that's simply not have SVN works. Agreed. I understand how Svn works, and it's fine how it works. But I'm arguing that I'd like to see an additional type of object that would be useful... A similar kind of workflow for SVN would be: Main work: /trunk Trunk Stable tag or branch: /tags/trunk-stable or /branches/trunk- stable Do work in /trunk, as things are declared stable merge to /branches/trunk-stable. While I have in the past been able to sympathize with people looking for CVS-style tags (and still do to some extent), I think Subversion style Tags are far more superior primarily from the fact that you can track any changes that are happening to the tag, which you could not do with CVS. Ben Subversion implements a versioned filesystem model (add, cp, mv, rm). If it also had a notion of a symlink (ln) that allows reference to path@revision, then it gives the same tracking of changes to a tag that you mention. But then other operations like checkout operate on what it points to. Then you really get baseline-label-tag type semantics instead of branch semantics. And to get those semantics, you don't really need hook scripts or special permissions to treat them specially. -Steve
Re: Tags - Symbolic names instead of Directory copy?
From: Varnau, Steve (Seaquest RD) steve.var...@hp.com To: BRM bm_witn...@yahoo.com; users@subversion.apache.org users@subversion.apache.org Cc: Thorsten Schöning tschoen...@am-soft.de Sent: Thursday, May 23, 2013 1:40 PM Subject: RE: Tags - Symbolic names instead of Directory copy? From: BRM [mailto:bm_witn...@yahoo.com] From: Thorsten Schöning tschoen...@am-soft.de To: users@subversion.apache.org Sent: Thursday, May 23, 2013 2:49 AM Subject: Re: Tags - Symbolic names instead of Directory copy? G uten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think he's thinking of CVS style tags, which are mutable in that you can modify which version of different files have the tag. So everyone works on HEAD and a STABLE tag progresses across it as developers decide different ports are stable. My example was a poor choice, as I prefer non-mutable tags, but there are certainly use-cases for mutable and non-mutable. There are certainly examples from other versioning tools. Baselines concept in ClearCase, that can be defined then locked. But those get too complex very fast. I really prefer the kind of simplicity in Svn. However, as you've mentioned and was more at length discusses elsewhere that's simply not have SVN works. Agreed. I understand how Svn works, and it's fine how it works. But I'm arguing that I'd like to see an additional type of object that would be useful... One way to do that would be to have another directory that you have the hook scripts configured to make read-only. So: /trunk /branches /tags /tags-readOnly Again, you're going to a hook-script to do it as that is how SVN enforces it best. Yes, there is the permissions structure but there's no easy way to do a globular matching like the following: [/*readOnly*] @users = r That is certainly one feature that would be very handy if ever implemented. A similar kind of workflow for SVN would be: Main work: /trunk Trunk Stable tag or branch: /tags/trunk-stable or /branches/trunk- stable Do work in /trunk, as things are declared stable merge to /branches/trunk-stable. While I have in the past been able to sympathize with people looking for CVS-style tags (and still do to some extent), I think Subversion style Tags are far more superior primarily from the fact that you can track any changes that are happening to the tag, which you could not do with CVS. Ben Subversion implements a versioned filesystem model (add, cp, mv, rm). If it also had a notion of a symlink (ln) that allows reference to path@revision, then it gives the same tracking of changes to a tag that you mention. But then other operations like checkout operate on what it points to. Then you really get baseline-label-tag type semantics instead of branch semantics. And to get those semantics, you don't really need hook scripts or special permissions to treat them
RE: Tags - Symbolic names instead of Directory copy?
-Original Message- From: BRM [mailto:bm_witn...@yahoo.com] Sent: Thursday, May 23, 2013 10:59 To: Varnau, Steve (Seaquest RD); users@subversion.apache.org Subject: Re: Tags - Symbolic names instead of Directory copy? From: Varnau, Steve (Seaquest RD) steve.var...@hp.com To: BRM bm_witn...@yahoo.com; users@subversion.apache.org users@subversion.apache.org Cc: Thorsten Schöning tschoen...@am-soft.de Sent: Thursday, May 23, 2013 1:40 PM Subject: RE: Tags - Symbolic names instead of Directory copy? From: BRM [mailto:bm_witn...@yahoo.com] From: Thorsten Schöning tschoen...@am-soft.de To: users@subversion.apache.org Sent: Thursday, May 23, 2013 2:49 AM Subject: Re: Tags - Symbolic names instead of Directory copy? G uten Tag Varnau, Steve (Seaquest RD), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: In my opinion, the same semantics work less well for tags. My biased mind-set is that a “tag” is a name identifying a specific version of code (a cross product of “branch” and “revision”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. Simply use them that way, like you said for branches. But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share the same semantics. Checkout is fine, I get the right version of the code. Update gives me the message that my workspace is up to date. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. I think he's thinking of CVS style tags, which are mutable in that you can modify which version of different files have the tag. So everyone works on HEAD and a STABLE tag progresses across it as developers decide different ports are stable. My example was a poor choice, as I prefer non-mutable tags, but there are certainly use-cases for mutable and non-mutable. There are certainly examples from other versioning tools. Baselines concept in ClearCase, that can be defined then locked. But those get too complex very fast. I really prefer the kind of simplicity in Svn. However, as you've mentioned and was more at length discusses elsewhere that's simply not have SVN works. Agreed. I understand how Svn works, and it's fine how it works. But I'm arguing that I'd like to see an additional type of object that would be useful... One way to do that would be to have another directory that you have the hook scripts configured to make read-only. So: /trunk /branches /tags /tags-readOnly Again, you're going to a hook-script to do it as that is how SVN enforces it best. Yes, there is the permissions structure but there's no easy way to do a globular matching like the following: [/*readOnly*] @users = r That is certainly one feature that would be very handy if ever implemented. A similar kind of workflow for SVN would be: Main work: /trunk Trunk Stable tag or branch: /tags/trunk-stable or /branches/trunk- stable Do work in /trunk, as things are declared stable merge to /branches/trunk-stable. While I have in the past been able to sympathize with people looking for CVS-style tags (and still do to some extent), I think Subversion style Tags are far more superior primarily from the fact that you can track any changes that are happening to the tag, which you could not do with CVS. Ben Subversion implements a versioned filesystem model (add, cp, mv, rm). If it also had a notion of a symlink (ln) that allows reference to path@revision, then it gives the same
Tags - Symbolic names instead of Directory copy?
Hi all, I'm hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread. That topic did, however, touch on tags. As discussed previously, tags as a convention use the same mechanism as the branches convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the branch work as expected. (checkout, update, commit) In my opinion, the same semantics work less well for tags. My biased mind-set is that a tag is a name identifying a specific version of code (a cross product of branch and revision). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout. But a tag that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. * Checkout is fine, I get the right version of the code. * Update gives me the message that my workspace is up to date. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. I think I'm working on ^trunk@HEAD, but I'm not. * Commit does not send changes the tagged branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn't set up right, it's even worse. I have a change to roll back, when I eventually notice the mistake. Due to those unfortunate semantics, we've do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don't have symbolic names, but we do get the right semantics. We have a couple hundred developers and hundreds of branches, but we do without symbolic tags. Yes, I know I'm stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can't implement proper hook scripts on our replicated repos.) So, am not saying there is anything fundamentally wrong with how tags work now. They just don't fit our desired semantics, so we don't use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. -Steve
Re: Tags - Symbolic names instead of Directory copy?
On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest RD) wrote: Hi all, I'm hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread. That topic did, however, touch on tags. As discussed previously, tags as a convention use the same mechanism as the branches convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the branch work as expected. (checkout, update, commit) In my opinion, the same semantics work less well for tags. My biased mind-set is that a tag is a name identifying a specific version of code (a cross product of branch and revision). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout. Tags are intended to be immutable. By your convention (not a bad one at all), a tag would be a symbolic name for some part of the repository tree at a specific revision. You could name all your tags this way, e.g. ^/tags/trunk_at_r123 for the above-named peg revision. This would be simpler than asking developers to remember the revision from which they are working, then type in the appropriate syntax. If a tag becomes obsolete (i.e. a fatal error is found in it), just delete it, then create a new tag from the appropriate trunk revision. But a tag that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. * Checkout is fine, I get the right version of the code. * Update gives me the message that my workspace is up to date. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. I think I'm working on ^trunk@HEAD, but I'm not. * Commit does not send changes the tagged branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn't set up right, it's even worse. I have a change to roll back, when I eventually notice the mistake. Usually only the build system (or developers trying to fix a specific bug) will check out a tag. Developers modifying code would not check out tags. Updating a tag, if it is immutable, is expected to be a no-op. A pre-commit hook would prevent commits to the tag. Due to those unfortunate semantics, we've do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don't have symbolic names, but we do get the right semantics. We have a couple hundred developers and hundreds of branches, but we do without symbolic tags. Yes, I know I'm stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can't implement proper hook scripts on our replicated repos.) You could have the same problem by checking out a branch and then switching to trunk. Which set of updates are you going to get? Which set of updates are going to be committed, and to where? I avoid that kind of confusion by not using svn switch. But I work in a simpler repository structure (a small number of developers with most development on trunk). It sounds like the root of your problem is not being able to implement a proper pre-commit hook to make the tags directory immutable. Tools are supposed to help perform your tasks more easily and reliably, and help you catch the mistakes you will inevitably make. If you aren't allowed to configure the tool to do this, it's not the tool's fault (or the concept). A new programmer recently asked me when she would stop making stupid mistakes. I replied never - I spend half of my time making mistakes and half of my time fixing them. After 1,000,000+ lines of code, I still make stupid mistakes. That's what testing is all about. So, am not saying there is anything fundamentally wrong with how tags work now. They just don't fit our desired semantics, so we don't use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. I'd say tags don't fit your repository configuration. See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Tags - Symbolic names instead of Directory copy?
On 23.05.2013 04:33, David Chapman wrote: On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest RD) wrote: So, am not saying there is anything fundamentally wrong with how “tags” work now. They just don’t fit our desired semantics, so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. I'd say tags don't fit your repository configuration. See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository. I'm confused ... why would you need a special pre-commit hook for something like that? I would expect access control to be good enough. Just make the tags tree in the repository read-only for most users. (N.B., having actually immutable tags would be a nice feature, but they're not required to solve your problem.) -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Tags - Symbolic names instead of Directory copy?
On 5/22/2013 7:56 PM, Branko Čibej wrote: On 23.05.2013 04:33, David Chapman wrote: On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest RD) wrote: So, am not saying there is anything fundamentally wrong with how “tags” work now. They just don’t fit our desired semantics, so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. I'd say tags don't fit your repository configuration. See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository. I'm confused ... why would you need a special pre-commit hook for something like that? I would expect access control to be good enough. Just make the tags tree in the repository read-only for most users. (N.B., having actually immutable tags would be a nice feature, but they're not required to solve your problem.) Access controls implies more than what the original poster was asking. Right now anyone can make a tag in his development environment simply by recalling the revision number. Access controls could work and are a reasonable suggestion in many cases. I tend not to think of them because I usually work in more-open environments where anyone can commit. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Tags - Symbolic names instead of Directory copy?
On Wed, 22 May 2013 19:33:33 +, David Chapman wrote: ... Usually only the build system (or developers trying to fix a specific bug) will check out a tag. Developers modifying code would not check out tags. Unless they are using externals. Letting external point to a non-tag thing isn't good idea (because the tags you make of your project wouldn't fix the externals to a tagged version). And then you run into some workflow turbulence when you start modifying within the externals. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
