Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

  •  
     
    story #8089 forbid svn tags modifications (part 2)
Actions
Summary
svn admin
forbid svn tags modifications (part 2)

When my repository layout is:

/
|-- trunk
|-- tags
`-- branches

Then modifications below "/tags" is forbidden

Functional and admin

As of today, there is already a SVN "immutable tags" implementation that prevent tags modifications with repository shaped like:

.
|-- moduleA
|   |-- trunk
|   |   `-- files and stuff
|   `-- tags
|       `-- ... tag stuff
`-- moduleB
    |-- trunk
    |   `-- files and stuff
    `-- tags
        `-- ... tag stuff

This story is about adding the same feature when the repository looks like:

.
|-- trunk
|   |-- moduleA
|   |   `-- files and stuff
|   |-- moduleB
|   `-- ... other modules
`-- tags
    `-- tag stuff

As a svn admin, I will have the possibility to select between:

  1. No SVN "immutable tags" (default)
  2. SVN tags immutable when having modules at root (previous implementation)
  3. SVN tags immutable when trunk/tags/branches at root (new)

Note: all projects that already use the "immutable tags" feature, will be converted to option 2 by default

SVN operations

Translated in svn terms, it means that, for any operations that have /tags as a target (/tags must be at root of repository):

  • 'A' (addition) operations should be allowed as long as the target directory doesn't exist
  • 'U' (update), '_U' (update of properties), 'UU' (update of properties + content) or 'D' (delete) operations should be forbidden

The changes with current implementation are:

  • As of today, all 'A' operations are allowed
  • As of today, Update of properties are not taken into account

'A', 'U', ... letters are from official SVN documentation: http://svnbook.red-bean.com/en/1.7/svn.ref.svnlook.c.changed.html

Therefore, given the following tree:

/trunk/moduleA/bla
/trunk/moduleB/blo
/trunk/tags/
  • (OK) svn mkdir ^/trunk/moduleA
  • (OK) svn cp ^/trunk/moduleA ^/tags/moduleA/v1
  • (ERR) svn cp ^/trunk/moduleA ^tags/moduleA/v1
  • (OK) svn cp ^/trunk/moduleA ^/tags/moduleA/v2
  • (OK) svn mkdir ^/tags/moduleB/stuff
  • (OK) svn cp ^/trunk/moduleA ^/tags/moduleB/stuff/toto
  • (ERR) svn rm ^/trunk/moduleB
  • (ERR) svn proposet svn:ignore ... ^/tags/moduleA/v1
  • (OK) svn mkdir ^/moduleA/tags/
  • (OK) svn cp ^/trunk/moduleA ^/moduleA/v1
  • (OK) svn cp ^/trunk/moduleA ^/moduleA/v1
  • (OK) svn cp ^/trunk ^/tags/v1
  • (ERR) svn cp ^/trunk ^/tags/v1
  • (OK) svn cp ^/trunk/moduleA ^/tags/v2
  • (OK) svn cp ^/trunk ^/tags/moduleA/v3

I highlighted the edge cases, were the behaviour is technically correct but result might be counterintuitive.

SVN Operations corrections

As of today, some operations are allowed inside tags whereas it should fail, those use cases should be fixed as well:

  • (ERR) svn co ^/submodule/tags/V1 && touch toto && svn add toto && svn commit -m "add in tag"
  • (ERR) svn co ^/tags/V1 && touch toto && svn add toto && svn commit -m "add in tag"
Empty
Nicolas Terray (nterray), Nouha Terzi (terzino), Salma MOAKHAR (moakhars), Denis PILAT (denis_pilat), Yannis ROSSETTO (rossettoy)
Status
Empty
Done
Development
  • [ ] Does it involves User Interface? 
  • [ ] Are there any mockups?
  • [ ] Are permissions checked?
  • [ ] Does it need Javascript development?
  • [ ] Does it need a forge upgrade bucket?
  • [ ] Does it need to execute things in system events?
  • [ ] Does it impact project creation (templates)?
  • [ ] Is it exploratory?
Empty
Details
#8089
Manuel Vacelet (vaceletm)
2015-06-16 16:17
2015-05-25 10:31
8108

References
Artifact links
Empty
Referencing story #8089

Artifact Tracker v5

rel #8112 8.3
epic #3225 Subversion improvements
story #8308 generic tag path specification

Git commit

tuleap/tuleap/stable

Merge commit 'refs/changes/23/4023/2' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD 80da5c33ea
User avatar Benjamin Dauton (bdauton_enalean) , 2015-06-02 12:12
story #8089: Mustachify SVN general settings f1ee3959a1
User avatar Yannis ROSSETTO (rossettoy) , 2015-05-29 11:48
Merge commit 'refs/changes/26/4026/12' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD df009301fd
User avatar Benjamin Dauton (bdauton_enalean) , 2015-06-09 14:35
story #8089: forbid svn tags modifications (part 2) a5956737cd
User avatar Nicolas Terray (nterray) , 2015-06-08 17:22

Release

release #107
Display settings

Follow-ups

User avatar
Manuel Vacelet (vaceletm)2015-06-03 09:56
Ok we will go on prop2 but it has an impact on estim (2 -> 3)
The REST part is possible but should be treated as a separate story (we can estimate it too if you want)
User avatar
Nouha Terzi (terzino)2015-06-03 08:27

Please see below The requester's answer:

prop 1 seems complex to implement/support. I am afraid that we fall one day or the other in a non-supported schema.
prop 2 is more realistic to my opinion.

To make prop2 even better, it would be very convenient to be able to control the white-list via the REST api.

regards,

Nouha

User avatar
Manuel Vacelet (vaceletm)2015-05-29 17:42

There is an important point raised by the team:

Given:

.
|-- trunk
|   |-- moduleA
|   |   `-- files and stuff
|   |-- moduleB
|   `-- ... other modules
`-- tags
    |-- moduleA
    `-- v1

How are we supposed to distinguish:

  • svn cp ^/trunk/moduleA ^/tags/moduleA/v2 (should be allowed because it's a partial tag)
  • svn cp ^/trunk ^/tags/v1/bla (should be because blocked, v1 already exists)

From SVN operations stand point, it's exactly the same operations: "add of something bellow an existing path in /tags"

The team has 2 proposal to work around this limitation:

  • Only allow creation of "writable subtags" if the name match something in trunk (here: write in ^/tags/moduleA is permitted because there is ^/trunk/moduleA)
    • Pro: it's automatic
    • Cons:
      • there might be corner cases like having a subdirectory in trunk named like a tag (eg. ^/trunk/v1)
      • there is a little bit of magic that can trig giant headache to support teams
  • Ask SVN admin to whitelist the modules:
    • By default all writes bellow ^/tags/*/ are forbidden
    • But admin can decide that "moduleA" would be overridable (with a textbox in SVN admin)
    • Pro: it's explicit
    • Cons; it's manual (ie. admin have to whitelist all modules)

Please review and answer ASAP as we are cannot continue development without your decision.

 

User avatar
Yannis ROSSETTO (rossettoy)2015-05-29 13:35
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
Manuel Vacelet (vaceletm)2015-05-29 11:55
I fixed a typo in the acceptance criteria.

Moreover, there is "(OK) svn cp ^/trunk/moduleA ^/trunk/moduleB/stuff/toto" as acceptance criteria.
I'm pretty sure that, given the updated request from nouha (SVN Operations corrections) that this will lead to an error as it's an operation bellow an existing tag but I'm don't know if we will be able to detect such operations. This should be checked by developers.
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
  • CC list Nicolas Terray (nterray), Yannis ROSSETTO (rossettoy) added
User avatar
Manuel Vacelet (vaceletm)2015-05-25 18:54
Those use case were not taken into account, I added them to the acceptance criteria.

Thanks!
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
Nouha Terzi (terzino)2015-05-25 11:53
In the current implementation, even if the option is enabled, If the commit contents only files to add, it doesn't fail on a tag path.
/svnroot/submodule/tags/V1
svn add ... (some files)
svn commit
This should have failed, it is not the case.

I were wondering, if with the new implementation, that is supposed to prohibit this scenario for tags under /root directory, the fix will be backported to tags under submodules, too?
User avatar
Manuel Vacelet (vaceletm)2015-05-25 11:19
Hi Nouha,

I don't understand your question, could you please highlight with a concrete test case (layout + svn operations) ?
User avatar
Nouha Terzi (terzino)2015-05-25 10:53
Hello Manuel,

Will the changes be backported to the current implementation,too?
Thus even tags that are not at the root directory the svn cp will be forbidden?
User avatar
Manuel Vacelet (vaceletm)2015-05-25 10:38
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
  • CC list set to Denis PILAT (denis_pilat), Salma MOAKHAR (moakhars), Nouha Terzi (terzino)