On Tue, 28 Sep 2004 12:17:23 -0400, Gary Feldman <g1list_1a@marsdome.com> wrote:
> Even when properly organized, it's confusing to navigate. That's because
> a. You have to remember a particular directory structure in the
> repository that doesn't match your working copy. Typically, your
> working copy would be in ~/projects/ThisProject/src, but in the
> repository, it's http://svn/projects/ThisProject/trunk/src.
Arbitrary layout decision. You could have easily said
.../trunk/ThisProject/src or even .../ThisProject/src (thats my
personal layout, actually) - there is nothing which says trunk has to
be named trunk, or that you have to nest one level within the other.
Indeed, I also have separate folders for holding exploratory branches
and maintenance branches - but I could have put these both as
subdirectories within branches.
> b. There's hidden meaning in the directories. If you're used to
> just looking at the last directory name in the path (e.g., if that's how
> your shell prompt is set, which is a very common approach), you can't
> tell whether you're looking at a legitimate source tree or Subversion's
> manifestation of a tag. Some of the directories are fulfilling the role
> of directories; some aren't. That makes the concept of "directory" more
> confusing, and breaks, at a conceptual level, the design principle that
> a given object should only do one thing.
There is no hidden meaning, the meaning is assigned by the person who
decided the repository layout. You are dealing with maintenance and
promotion processes here with tags and branches, to think someone will
just magically 'get it' without having policy explained to them is
foolhardy.
> c. There's no guarantee of consistency or portability of knowledge.
> If you've been working on ProjectA in your company that organizes
> things one way, and then move to a different group that organizes things
> another way, you're forced to learn a new directory structure. Even
> worse, you can issue a cp command that you think is creating an
> effective tag, and it can even work with no error message, but it's
> still wrong - possibly very wrong.
With tags and branches as properties of the file, you have fixed
yourself to a very limited subset of possible processes for
maintenance and promotion. In that sense, a user will be able to
figure out the policy which is in place much quicker based on previous
experience, because the tool is restricting what policies are
possible.
Restricting which policies are possible to get around people not
having policy explained to them doesn't make sense. Personally, I'd
rather have the option to set all aspects of the policy myself.
> d. There's no interactive help. If I forget the exact options and
> order to the svn merge command, I can use svn help merge. But if I
> forget exactly how to structure the tag operation, I can't say svn help
> tag and have it tell me enough to determine the exact path to use as the
> target.
This is yet again domain specific knowledge. I could certainly see
multiple tag types being allowed, one to indicate code has been
promoted to the QA department, one to indicate exact version of an
integration build, one to indicate actual RTM version, and so on. Each
of these may have naming conventions. Access to the folders to make or
hide tags may be restricted to people in certain roles.
In no professional or open-source development environment I have been
apart of, is it considered correct to arbistrarily choose a tag or
branch name. The name is set by policy. If I create a new subversion
branch called 'pink-fluffy-bunny' in the collab.net repository, I
would probably quickly lose all committer rights.
I understand the desire to have the tool enforce some of this policy
for you automatically, but it doesn't gain functionality, it just
loses flexability.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 28 21:59:43 2004