0

Two teams are working on two different projects "A" and "B". Some files are common to both projects and are stored in a directory "Common". When a release date of project A approaches, the team of project A does not want to be bothered by modifications to "Common" made by team "B".

Most people like branches for such issues but i don't. What i want is to give a simple possibility to team A to

1) ignore all modifications made by team B to Common files

2) share modifications of Common files among team A members

Here are the A,B,Common directories as stored on svn :

Common
.. A
.. B

The idea i am trying to implement is to make "Common" directory read-only and not updatable to team A. If they really want to modify Common files, they will have to copy them in directory "A" and commit them.

Is there a way, ideally a simple and elegant one, to do "just that" ?

NB : this is a simplified presentation of the issue. There are more than just two teams, and more than just one "common" repository

NB2 : all teams use tortoiseSVN

Benoît
  • 16,798
  • 8
  • 46
  • 66
  • 1
    This sounds like it's exactly what branches were invented for. Why do you think you don't like them to use for it then? – sbi Aug 10 '09 at 09:11
  • Using branches, no difference can be found when modifying A or Common. I want to make it slightly more difficult to modify Common (just to make sure the developper does think a bit before doing it) – Benoît Aug 11 '09 at 06:15

2 Answers2

6

A thought - if you used svn:externals to reference your Common(s) you are able to specify revision number (as opposed to head revision). This will enable you to switch to controlled revision when the release date approaches.

Rashack
  • 4,667
  • 2
  • 26
  • 35
1

This is the "untouchable library" problem which I try to describe in another answer

Simply put - use externals.

Community
  • 1
  • 1
Jim T
  • 12,336
  • 5
  • 29
  • 43