Hello all,
Branko Čibej wrote:
> BTW, because it lets you define branch and tag namespaces in any way you
> want, Subversion's way is _more_ flexible than most other VC systems
> I've seen. I think people are just irrationally afraid of this
> genericity and flexibility.
I don't think 'irritionally afraid' would be the correct term, I'd call it
'getting lost in the ocean of possibilities'.
I think that many people (including me), cannot oversee what the system is
actually doing/capable of, exactly due to this genericity and flexibility.
Taking myself as an example, as naive user, I just want to 'do version
management'. To questions like 'how should I layout the repository', 'how do I
manage branches/tags', and many other questions, the answer is (to a large
degree) 'anything you like'.
That isn't exactly helping in solving my problem.
In other words, I feel sometimes a bit 'lost' with these matters.
[ not that I critize any one here (especially the developers!). You are all
doing a wonderful job of making software, the software is just too powerful
for me to (fully) understand.
]
> Would you feel better if we had a "svn branch" and "svn tag" command?
in one way, yes. It gives me a hard border/baseline to think out the solution
to my problem against.
in another way, no. No doubt, I will want to get around the border tomorrow
and do things just a tad different.
I very much doubt that this problem should be solved in software, in
particular at the server side.
Having a set of standard procedures for the standard things would go a long
way. A kind of user guide for using a version management system.
In the svn-book, and many other books about SCM, the command to create or
merge a branch is given, the command to create a tag is given, but the
procedure as a whole is not (the 1 line command is kind of the end result of
following a procedure).
For example, to create a branch (and I have never done this in real life with
svn, so don't assume that the procedure below makes any sense):
(assuming project/{trunk,branches,tags} repository layout):
1. come up with a nice name for your new branch (assuming 'newname')
2. check that the name is not in use in /project/branches
3. copy the trunk to the branch
svn copy ..../project/trunk .../project/branches/newname
4. make a tag to merge back to the trunk against later
svn copy ..../project/branches/newname \
.../project/tags/newname-branch-<repo-number>
While this is not earth moving in any way, it does make these procedures (and
use of svn/SCM in general) more tangible for new/inexperienced users.
(ie such procedures create a nice starting point, an island in the ocean imho).
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 12 13:44:43 2005