You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Weintraub <qa...@gmail.com> on 2009/09/08 15:01:48 UTC
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
The problem is that there is no way to tell if a copy operation is a tag, a
branch, or someone is merely copying files. They all use the same "svn cp"
command.
Basically, if something is copied to the "tags" directory, it is a tag. If
it's copied to the branches directory, it is a branch, and if it is copied
somewhere else, it is a regular copy.
The best I can suggest is user training. Repeat over and over again to your
users that "Tags go here...". Remember that this is a revision control
system, so you can always undo what the developers did, and you always know
who was not doing what they're suppose to be doing.
It might be possible to examine a svnlook changed output to see that if
someone is copying the entire project, we can assume it is a tag. But that
might be a bit dangerous.
On Thu, Sep 3, 2009 at 8:23 AM, Georges Martinez-Valentin <
georges.martinez-valentin@mgeups.com> wrote:
>
> Hello,
>
>
> *my problem *: I want to check than any user make tags in the correct
> directory.
> As we use (tags, trunk & branches) directories for all the project
> developpment, we want than all tags, are made in the "project/tags"
> directory.
>
> I try to use pre-commit hook, but i get 2 problems :
>
> 1. i don't arrive to determine whether if the current transation is a
> COMMITtransaction or if it is a TAG transaction.
> 2. Any where, using svnlook, i get only the repository path of the
> project, and not the final directory name as "tags".
>
>
>
>
> Here below more informations about our organization, see below the draft :
>
> /SNVroot---------/Project 1------------/tags
> | /branches
> | /trunk
> |
> |---------/Project 2------------/tags
> | /branches
> | /trunk
> |
> |---------/Project 3------------/tags
> | /branches
> | /trunk
> |
>
> Actually, i use pre-commit hook, for check empty log. And it is running
> well.
>
>
> *my questions :*
>
> 1. do you think, than i can solve this point, using pre-commit hooks ?
> 2. If yes, how ?
> 3. how can i know if current transaction is a TAG or COMMIT one ?
>
>
>
> Thanks for your help, and for your nice tool. (old CVS user).
>
>
>
>
> Cordialement / Regards
> *
> Georges Martinez-Valentin* | *APC by Schneider Electric* | *IT
> Business* | *Senior Firmware Engineer - Management products* *
> Phone:* +(33).(0)4.76.18.33.41 | *
> Email:* georges.martinez-valentin@mgeups.com | *Site:* *www.apc-mge.com
> * <http://www.apc-mge.com/> *
> Address:* 140 avenue Jean KUNTZMANN ZIRST Montbonnot St Martin - 38334 ST
> ISMIER
> *** Please consider the environment before printing this e-mail
>
>
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392524
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: Tuesday, September 08, 2009 11:23 PM
> To: David Weintraub
> Cc: Georges Martinez-Valentin; users@subversion.tigris.org
> Subject: Re: Svn hooks pre-commit - How, for tag operation, check than
user
> make the tag operation in tags directory
>
[snip]
> OK, you've explained how it works and what it can do. But what
advantage
> would maintaining a separate list of paths@revisions with a label on
it
> really give us, when our goal is to make tags, as they exist in
Subversion
> today, read-only?
Is that the goal? I understand branches, but I'm not sure tags need to
work in the same way. Making a read-only branch is not necessarily the
solution that everyone wants.
Where I am, we release very often, so I would have a repo chock-full of
tags, if we used them. As it is, we use the 'revision number' approach
and get old versions out based on their history. It's a more manual
task, but we don't usually need to get older versions very often.
This is where I think the revision number tag is a better solution...
and in fact, I would like to consider both the branch-based and the
revision-based tags as part of subversion. Perhaps if we called
branch-based as tags, and revision-based as 'labels', it might help?
> > However, I'd take straight revision aliases if that would help.
>
> You've said so earlier, but I thought we had determined that straight
> revision aliases don't buy us much because you also need to specify
> which paths in the versioned tree you want this label to apply to.
You don't need paths if your labels were unique. It might be too much of
a restriction for some people though. However, if your label included
some part of the path to make it unique, that would be just fine. I
guess if people have multiple projects in their repository and want to
release them all with labels like 'Release 1', then that is not going to
work, but 'projectA Release 1', 'projectB Release 1' are perfectly ok.
I don't see the problem with prepending a path to the label text either,
isn't this what would happen anyway, and it wouldn't be too troublesome
if it was used to uniquely specify which label you wanted - you don't
need to type out the whole path, just enough to make it unique.
Eg. You have 2 projects, A and B and you insist on labelling them both
"Release 1". Svn stores 'Release1' as the label text, but also stores
'/projectA' or '/projectB' in there as well. When a user tries to "svn
co -rRelease1", it will fail as it cannot tell which label was intended,
so we need to use "svn co -rProjectA/Release1" instead. So we store the
label as the full path+label text, and then specify as much of it (from
the right) as is needed to determine a unique label. (eg.
/root/trunk/projectA/ gets labelled with 'Release1' even though there is
already a Release1 used for project. Now the only part needed to
determine which 'Release1' you meant would be to work backwards through
the path and use ProjectA part of it, not the whole path, which gives us
the means to have unique labels without much hassle on the part of the
user).
The benefit of using labels like this is that branch-based tags can
still be used, and that the mechanism for retrieving the labelled
versions nearly already exists, you just need a lookup of name to
revision.
Maybe I'm missing something, but this appears to be very easy to
implement, and very easy to understand, and because the labels would be
stored in a separate section, it would be fast to search through them -
they'd be like an index to the repository.
If the topic is back on discussion, I'll have to have a long think about
it now. The above are my initial thoughts. Cheers guys.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392815
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 08, 2009 at 03:47:15PM -0400, David Weintraub wrote:
> What I want to be able to do is this:
>
> $ svn cmd -r<TAG>
>
> Subversion should figure out what to do, and do it quickly.
>
> One of the problems is what happens if a particular revision of a file is in
> more than one tag. How does your svn:tag property handle this? Do I have to
> create a new version the database to create a tag? (It's one of the things
> that happens which I am not found of now.)
You need to copy the file twice to get it tagged twice in the current
model. I see no realistic way to change that. Subversion is all about
the 3d-versioned-filesystem tree.
> Perforce has two ways to create tags. Number one is to create a tag, and
> then attach that tag to each and every file revision you want that tag on.
Subversion has no individual file revisions.
> Method #2 is more interesting and probably is more what we want.
> In that method, the tag contains a description of the change sets and paths
> for those change sets. In Perforce, a change set is equivalent to a
> Subversion revision number.
> Once you defined the file directory list and the change set revision number,
> your files are automatically considered tagged. You can even mix and match
> revisions if you like. These records can be locked to prevent them from
> being changed. See <
> http://perforce.com/perforce/doc.091/manuals/p4guide/06_codemgmt.html#1081816
> >.
>
> That would be the ideal system.
OK, you've explained how it works and what it can do. But what advantage
would maintaining a separate list of paths@revisions with a label on it
really give us, when our goal is to make tags, as they exist in Subversion
today, read-only?
In Subversion, a set of paths can be obtained by copying things
to some place in the versioned tree. This means that we do not need
to maintain lists of paths externally. The paths are in the versioned
tree already, we don't need a separate represention for them.
I'm not saying this is very great or very bad, just that it's part of
the basic idea of the model Subversion is using. Changing assumptions
about the basic model just to get tags read-only makes it very hard
to get a working solution.
> However, I'd take straight revision aliases if that would help.
You've said so earlier, but I thought we had determined that straight
revision aliases don't buy us much because you also need to specify
which paths in the versioned tree you want this label to apply to.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392684
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by David Weintraub <qa...@gmail.com>.
What I want to be able to do is this:
$ svn cmd -r<TAG>
Subversion should figure out what to do, and do it quickly.
One of the problems is what happens if a particular revision of a file is in
more than one tag. How does your svn:tag property handle this? Do I have to
create a new version the database to create a tag? (It's one of the things
that happens which I am not found of now.)
Perforce has two ways to create tags. Number one is to create a tag, and
then attach that tag to each and every file revision you want that tag on.
Method #2 is more interesting and probably is more what we want.
In that method, the tag contains a description of the change sets and paths
for those change sets. In Perforce, a change set is equivalent to a
Subversion revision number.
Once you defined the file directory list and the change set revision number,
your files are automatically considered tagged. You can even mix and match
revisions if you like. These records can be locked to prevent them from
being changed. See <
http://perforce.com/perforce/doc.091/manuals/p4guide/06_codemgmt.html#1081816
>.
That would be the ideal system. However, I'd take straight revision aliases
if that would help.
On Tue, Sep 8, 2009 at 1:39 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Sep 08, 2009 at 12:28:09PM -0400, David Weintraub wrote:
> > But, that is still a stop gap measure. Tags should have been a built in
> > concept from the get-go. Occasionally, there is a discussion on this
> mailing
> > list about the lack of true tags. One recommendation is to make tags
> aliases
> > of revisions, so where you use a revision number, you could use a tag to
> > represent that revision. You'd need some commands to create these
> revision
> > aliases, more commands to lock them, and even pre-tag/post-tag hooks to
> > allow you to define what a tag can and cannot look like.
>
> I don't think that implementing tags as aliases of revisions is a good
> idea.
>
> You've named some disadvantages of this approach, e.g. a huge
> implementation
> effort. In addition to this, Subversion's concept of a single versioned
> tree
> means that it provides logical boundaries scoped by a path namespace.
> You can't simply say "r33728 is v1.0", because you also need a path
> pointing to the root of the thing you declare being v1.0 to make sense
> of this statement.
>
> Is this thing a release branch? Is it trunk? Is it some submodule of
> some subcomponent of the persistence backend of your web application?
>
> So, given this, I think the best we could do this is define a new
> property in the svn: propery namespace, that is versioned, just like
> svn:mergeinfo, and sits at a path (we could require this path to be a
> directory). Let's call it "svn:tag". Since the name is in the "svn:"
> namespace any third party client can use this name and be interoperable.
>
> The svn client would set this property as part of the commit transaction
> when the user runs 'svn copy --tag', which would have the same effect as
> doing a copy and setting the svn:tag property on the copy destination in
> a subsequent commit, except that it's done in a single commit transaction.
>
> Upon commit, the server would walk up towards the root of the repository
> filesystem and check for the existence of an svn:tag property at any
> of the parent directories, in the revision the transaction is based
> on (just checking HEAD might be racy). Commits would be aborted if such
> a property was found.
>
> What if you want to change a tag? Just remove the property in HEAD,
> possibly update your WC, and try again.
>
> It's unlikely that people would remove the property accidentally,
> except if removing the entire directory. It would not be as easy
> anymore to make mistakes as it is now.
>
> This approach is both backwards-compatible and fairly easy to implement.
> People could manually set this property on their tag directories so that
> the server could take advantage of it when upgraded, and svn:tag-aware
> clients could take advantage of it even if the server does not know about
> it yet, by browsing the repository manually.
>
> Initially, the property's value would be undefined, but if the need ever
> arises we could add content to it to provide more information.
>
> In addition to this, we could have a similar property to designate
> branch boundaries (svn:branch). This would solve the dilemma of having
> to create svn:mergeinfo every single time people copy things, just
> because the copy could be a branch. Does the copy cross a branch
> boundary (an svn:branch property)? If so, create mergeinfo.
> If not, don't create mergeinfo, we're doing an intra-branch copy.
> svn copy --branch would create an svn:branch property at the
> destination.
>
> > If Subversion really didn't have any way to emulate tags, then we might
> have
> > seen some movement, but since we have a sloppy way to handle this, no
> > further work is done on it.
>
> Yes. I'll think about enhancing the above into a formal design proposal.
> Do you see anything wrong with the approach? I'm afraid that there might
> be a serious downside I'm overlooking.
>
> Stefan
>
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392626
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 08, 2009 at 12:28:09PM -0400, David Weintraub wrote:
> But, that is still a stop gap measure. Tags should have been a built in
> concept from the get-go. Occasionally, there is a discussion on this mailing
> list about the lack of true tags. One recommendation is to make tags aliases
> of revisions, so where you use a revision number, you could use a tag to
> represent that revision. You'd need some commands to create these revision
> aliases, more commands to lock them, and even pre-tag/post-tag hooks to
> allow you to define what a tag can and cannot look like.
I don't think that implementing tags as aliases of revisions is a good idea.
You've named some disadvantages of this approach, e.g. a huge implementation
effort. In addition to this, Subversion's concept of a single versioned tree
means that it provides logical boundaries scoped by a path namespace.
You can't simply say "r33728 is v1.0", because you also need a path
pointing to the root of the thing you declare being v1.0 to make sense
of this statement.
Is this thing a release branch? Is it trunk? Is it some submodule of
some subcomponent of the persistence backend of your web application?
So, given this, I think the best we could do this is define a new
property in the svn: propery namespace, that is versioned, just like
svn:mergeinfo, and sits at a path (we could require this path to be a
directory). Let's call it "svn:tag". Since the name is in the "svn:"
namespace any third party client can use this name and be interoperable.
The svn client would set this property as part of the commit transaction
when the user runs 'svn copy --tag', which would have the same effect as
doing a copy and setting the svn:tag property on the copy destination in
a subsequent commit, except that it's done in a single commit transaction.
Upon commit, the server would walk up towards the root of the repository
filesystem and check for the existence of an svn:tag property at any
of the parent directories, in the revision the transaction is based
on (just checking HEAD might be racy). Commits would be aborted if such
a property was found.
What if you want to change a tag? Just remove the property in HEAD,
possibly update your WC, and try again.
It's unlikely that people would remove the property accidentally,
except if removing the entire directory. It would not be as easy
anymore to make mistakes as it is now.
This approach is both backwards-compatible and fairly easy to implement.
People could manually set this property on their tag directories so that
the server could take advantage of it when upgraded, and svn:tag-aware
clients could take advantage of it even if the server does not know about
it yet, by browsing the repository manually.
Initially, the property's value would be undefined, but if the need ever
arises we could add content to it to provide more information.
In addition to this, we could have a similar property to designate
branch boundaries (svn:branch). This would solve the dilemma of having
to create svn:mergeinfo every single time people copy things, just
because the copy could be a branch. Does the copy cross a branch
boundary (an svn:branch property)? If so, create mergeinfo.
If not, don't create mergeinfo, we're doing an intra-branch copy.
svn copy --branch would create an svn:branch property at the
destination.
> If Subversion really didn't have any way to emulate tags, then we might have
> seen some movement, but since we have a sloppy way to handle this, no
> further work is done on it.
Yes. I'll think about enhancing the above into a formal design proposal.
Do you see anything wrong with the approach? I'm afraid that there might
be a serious downside I'm overlooking.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392584
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by David Weintraub <qa...@gmail.com>.
On Tue, Sep 8, 2009 at 11:44 AM, Stefan Sperling <st...@elego.de> wrote:
> While a wrong/deleted/modified tag is always a problem caused by human
> error, I'm beginning to doubt that we can keep telling people to simply
> be really, really careful, forever.
>
Actually, I agree with you. There is a lot in Subversion where we simply
tell users to be careful, and that's not a good attitude.
If I understood the question the user had, it was "how can I prevent tags
from being written to the wrong directories. Unfortunately, in Subversion,
there is no real way since tagging operations are similar to branching and
simply copying or moving directories. Is it a tag or is it a copy? We call
it a tag if its in the tag directory.
However, I don't think people carelessly do tagging operations. They may
simply decide to create a tag in another directory because it is convenient.
The big problem I have is that Subversion simply doesn't have the concept of
tags. We pretend that Subversion does tagging just like we pretended we
could tag files in SCCS. It is a work around, and a messy one at that.
Because of the lack ot tagging, comparing two tags is a mess:
$ svn diff http://subversion/dev/modules/adsuite/tags/ADS-5.4
http://subversion/dev/modules/adsuite/tags/ADS-5.5
If Subversion had tagging, we could have done this:
$ svn diff -rADS-5.4:ADS-5.5 http://subversion/dev/modules/adsuite/trunk
Or, more likely:
$ svn diff -rADS-5.4 .
Even worse, there is no concept of locking a tag. Tags are suppose to be
trusted snapshots of what my revision looked like at a certain moment in
time. To make sure tags aren't modified, most revision control systems let
you lock a tag to prevent someone from modifying it. In Subversion, you can
checkout a tag like you can any other directory, you can make your changes,
and you can commit those changes.
When I first used Subversion back in version 1.2, I was shocked by this. The
pre-commit trigger at that time allowed you to lock a directory to prevent
users from modifying it, but if you did that, users could not make tags. To
get around this, I ended up writing my own trigger that allows you to add a
directory to a particular location in the repository, but won't let you
commit changes to that directory. Thus, once you create a tag, it is locked.
I believe the current Python pre-commit trigger now does this.
But, that is still a stop gap measure. Tags should have been a built in
concept from the get-go. Occasionally, there is a discussion on this mailing
list about the lack of true tags. One recommendation is to make tags aliases
of revisions, so where you use a revision number, you could use a tag to
represent that revision. You'd need some commands to create these revision
aliases, more commands to lock them, and even pre-tag/post-tag hooks to
allow you to define what a tag can and cannot look like.
Most people and even the developers seem to agree with this approach, but
because we do have the ability to sort-of emulate tags, because of the need
to completely architect this new feature, because this feature would entail
changes in the server side and in the client side, and because of the
extensive restructuring of the Subversion data structure this might entail,
the idea of adding true tags to Subversion takes a backseat to more
important demands (performance, bug fixes, improvements in behavior, etc.)
If Subversion really didn't have any way to emulate tags, then we might have
seen some movement, but since we have a sloppy way to handle this, no
further work is done on it.
I don't think the existing solutions with pre-commit hooks are reliable
> enough. svnperms.py isn't the answer for complex real-world repositories.
> Having to write regexes to match paths in huge multi-project repositories
> with directory structures which happen to have evolved over time isn't
> that much fun.
>
I haven't had the pleasure of using svnperms.py. I understand it does a few
more things than the older Perl version of this script, but its structure
may be a bit more complex than what most people are looking for. I wrote my
own pre-commit trigger back in the 1.2 days that allows me to specify who
has commit access to the repository (read-only and read-write), and the
ability to create immutable tags (add-only), set properties, ban certain
file names and characters, and set templates for revision properties.
The big problem with a pre-commit hook, however, is that it is slow. Built
in permissioning would be much faster than running a script that has to read
in a control-file, parse it, and finally parse the user changes and see if
they match what you thought you put into the control-file.ini file..
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392558
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 08, 2009 at 11:01:48AM -0400, David Weintraub wrote:
> The problem is that there is no way to tell if a copy operation is a tag, a
> branch, or someone is merely copying files. They all use the same "svn cp"
> command.
>
> Basically, if something is copied to the "tags" directory, it is a tag. If
> it's copied to the branches directory, it is a branch, and if it is copied
> somewhere else, it is a regular copy.
>
> The best I can suggest is user training. Repeat over and over again to your
> users that "Tags go here...".
While a wrong/deleted/modified tag is always a problem caused by human
error, I'm beginning to doubt that we can keep telling people to simply
be really, raelly careful, forever.
People make errors, that's part of why we use tools to support us
when we're dealing with complicated tasks. I'm increasingly considering
that Subversion should make it possible to mark parts of the repository
tree as 'write once, then readonly'. It would avoid many problems caused
by human error.
I don't think the existing solutions with pre-commit hooks are reliable
enough. svnperms.py isn't the answer for complex real-world repositories.
Having to write regexes to match paths in huge multi-project repositories
with directory structures which happen to have evolved over time isn't
that much fun.
> Remember that this is a revision control
> system, so you can always undo what the developers did, and you always know
> who was not doing what they're suppose to be doing.
Yes, you can always undo everything, which is good. No data can get lost.
But there can still be subtle problems and people can waste *time*
trying to figure them out.
When you check out a tag to reproduce a problem, you don't readily know
if that tag is still in the same state as it was when it was created.
Which in itself is already a contradiction to what a tag is all about.
You have to run svn log to find out. Have you *ever* verified that
a tag you got from a Subversion repository was still sound? I haven't.
Maybe someone has modified e.g. a single file by accident when they
were working on a bugfix for that version, from a working copy checked
out of this tag, and no one noticed the accidental commit?
The fact that an accidental commit should not have happened and should
have been noticed and both these failures are based on human error does
not help much when you're actually hitting problems like this in practice.
People use IDEs which look rather like pilot cabinets of an airplane.
I'm not surprised that with all those buttons and dials in the way
people make errors. "Oops I must have right-clicked the wrong folder
when committing that months ago..."
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392538
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Svn hooks pre-commit - How, for tag operation, check than user
make the tag operation in tags directory
Posted by Georges Martinez-Valentin <ge...@mgeups.com>.
Hi David,
thanks for your answer.
Meanwhile my first email, i am looking for solution based on python 2.5
script (and Windows compliant).
I hope it is a good way to find tools on the Web.
If you have any links about this, i am very interesting
Cordialement / Regards
Georges Martinez-Valentin | APC by Schneider Electric | IT Business
| Senior Firmware Engineer - Management products
Phone: +(33).(0)4.76.18.33.41 |
Email: georges.martinez-valentin@mgeups.com | Site: www.apc-mge.com
Address: 140 avenue Jean KUNTZMANN ZIRST Montbonnot St Martin - 38334 ST
ISMIER
*** Please consider the environment before printing this e-mail
David Weintraub <qa...@gmail.com>
08/09/2009 17:01
A
Georges Martinez-Valentin <ge...@mgeups.com>
cc
users@subversion.tigris.org
Objet
Re: Svn hooks pre-commit - How, for tag operation, check than user make
the tag operation in tags directory
The problem is that there is no way to tell if a copy operation is a tag,
a branch, or someone is merely copying files. They all use the same "svn
cp" command.
Basically, if something is copied to the "tags" directory, it is a tag. If
it's copied to the branches directory, it is a branch, and if it is copied
somewhere else, it is a regular copy.
The best I can suggest is user training. Repeat over and over again to
your users that "Tags go here...". Remember that this is a revision
control system, so you can always undo what the developers did, and you
always know who was not doing what they're suppose to be doing.
It might be possible to examine a svnlook changed output to see that if
someone is copying the entire project, we can assume it is a tag. But that
might be a bit dangerous.
On Thu, Sep 3, 2009 at 8:23 AM, Georges Martinez-Valentin <
georges.martinez-valentin@mgeups.com> wrote:
Hello,
my problem : I want to check than any user make tags in the correct
directory.
As we use (tags, trunk & branches) directories for all the project
developpment, we want than all tags, are made in the "project/tags"
directory.
I try to use pre-commit hook, but i get 2 problems :
1. i don't arrive to determine whether if the current transation is a
COMMITtransaction or if it is a TAG transaction.
2. Any where, using svnlook, i get only the repository path of the
project, and not the final directory name as "tags".
Here below more informations about our organization, see below the draft :
/SNVroot---------/Project 1------------/tags
| /branches
| /trunk
|
|---------/Project 2------------/tags
| /branches
| /trunk
|
|---------/Project 3------------/tags
| /branches
| /trunk
|
Actually, i use pre-commit hook, for check empty log. And it is running
well.
my questions :
1. do you think, than i can solve this point, using pre-commit hooks
?
2. If yes, how ?
3. how can i know if current transaction is a TAG or COMMIT one ?
Thanks for your help, and for your nice tool. (old CVS user).
Cordialement / Regards
Georges Martinez-Valentin | APC by Schneider Electric | IT Business
| Senior Firmware Engineer - Management products
Phone: +(33).(0)4.76.18.33.41 |
Email: georges.martinez-valentin@mgeups.com | Site: www.apc-mge.com
Address: 140 avenue Jean KUNTZMANN ZIRST Montbonnot St Martin - 38334 ST
ISMIER
*** Please consider the environment before printing this e-mail
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392539
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].