> > (page 41, introduction to branching with branches dir)
> > I would add here a mention (likely a footnote) that there exists
> > a method (svn switch) which allow one to keep the same working
> > dir while moving from trunk to branch and opposite.
> >
>
> We cover that later in the chapter... a whole section dedicated to svn
> switch. I think that mentioning switch in the very beginning of the
> chapter would be too much information.
I have strong CVS background and while reading subversion book (and web
pages) I found asking myself a question 'hmm, so what, if I am to
branch, I have to reorganize directory dependencies?'. When I got to the
section about 'svn switch' it was 'eureka, I need not!' but this section
is far away from the discussions about repo dirs structure where those
thoughts come to mind. And that's the reason for the suggestions above.
And of course I don't suggest wide info about svn switch here, just some
footnote like 'You can move between the trunk and the branch using the
same working directory in your sandbox, take a look at svn switch
command in chapter ...'. The thing is also worth mentioning in appendix
(and webpage) for CVS users, some of whom are rather accustomed to
switching branches/trunk using cvs up -A /cvs up -r branchtag)
> > (chapter 4)
> > I would probably introduce tags first, branches and merges later.
> > Maybe my CVS habits makes me to think so but tags are simpler
> > concept. Moreover, I would either change chapter 4 title to
> > 'Branching, Merging and Tagging' or move tagging description to
> > separate chapter.
>
> This is a deliberate choice, actually. The "hard concept" is the idea
> of making a cheap copy. I want people to think of branches as normal
> copies, and tags as copies that don't change. So I introduce the copy
> concept first, show how it's useful for branching, then describe tagging
> as a secondary use of copying.
OK, I don't feel the idea completely but you are the author and you are
experienced Subversion user. Nevertheless I would add 'tagging' to the
chapter title, the tag concept is important in version control world.
By the way: does subversion allow me to do something similar to
cvs log -r oldtag -r newtag
(show log of the changes made between the two tags)? If so, it would
really be worth mentioning in the chapter about tags. If not, some
comment about possible workarounds, work habits etc would be nice too.
> > (general)
> > I would introduce early in the book and use consistently some
> > method of avoiding urls in the commands. Maybe
> > export SVNREP='http://my.repo.com/subversion'
> > and
> > svn checkout $SVNREP/mymodule
> > maybe something else....
>
> Why? Most people only do that sort of thing when they're about to
> execute 20 commands that require the same $SVNREP prefix. It's pretty
> uncommon to *ever* have to type a url in day to day work. This
> technique is more useful for scripts that do automated repository access
> with no working copies available.
OK, maybe I overrated the frequency of using URL-based commands.
As I am now reading administrative chapter, one more thing: it seems to
me, the whole backup, dump/restore, tx cleanup etc discussion is heavily
related towards the small repositories. For a long time while reading
the book I thought that the hot backup is some kind of cheap incremental
backup (you are frequently mentioning putting it inside post-commit),
then I found small paragraph telling that it is in fact copying the
whole repository somewhere. It maybe simple for 5MB repo but there are
larger (currently I co-admin CVS repository taking over 1GB of
compressed backup and over 5GB on disk). In fact, this matter made me to
think that subversion is far less mature than I tended to expect
initially. And I would recommend adding to the administration chapter
some section about managing the large repositories. I would suggest also
labelling efficiency-risky hints like hot backup in postcommit with some
kind of warning that this idea is valid for small repositories only.
I found also some other 'practice' problem. This is nice that svn move
is cheap but I would never tell that 'you can reorganize your repo
directory structure if you like'. What about all those clients who
checked out their copy of some modules? That's fine that subversion
allows to version directory operations but any real practice should
recommend being very conservative with repository reorganization.
By the way: the book does not tell what will happen in such a case:
(playerA) svn checkout <url>/some/module
(playerB) svn move some/module other/thing
(playerA) svn commit some/module
I guess some conflict will arise. How can it be resolved?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 17:51:45 2004