Josef Wolf wrote:
>On Wed, Jul 31, 2002 at 07:03:06PM +0200, Branko ??ibej wrote:
>
>
>
>>Nope, that's "svn switch"; quite similar, but entirely different. :-)
>>Which is not to say you couldn't have the same UI for both update and
>>switch, of course.
>>
>>
>
>So you "svn update" to go back/forth along a branch and "svn switch"
>to jump from one branch to another? Seems that I am beginning to
>understand :) Looks good. It was always hard to explain new co-workers
>the overload of the "cvs update" and its -A switch =8). What happens
>when you give "svn update" a wrong URL (one directory too deep or some
>such?)
>
You don't give "svn update" an URL, it doesn't accept URLs. "svn help
update", right?
[snip]
>>> | REVISION: |
>>> |-------------|
>>> | Latest | << corresponds to "HEAD"
>>> | Branch... | << pops up a dialog where you enter a number
>>>
>>>
>>>
>>You mean "URL" here, don't you? Branches aren't numbered in Subversion
>>(at least, not so it's visible to the user).
>>
>>
>
>Hmmm, I find it very confusing to speak about URLs when you really
>mean branches. Maybe I am too biased to cvs philosophy, but I think
>most SCM systems have a concept which is similar to cvs-branches.
>
Look, SVN does have branches, it's just that they're the same as
directories. "svn switch" is just like "svn update", except that you
give it an URL to update your working copy from -- that is, tell it
which directory your branch is in.
>>Tags, branches, and directories are all the same thing in Subversion.
>>What you're saying would make sense in CVS, but not in SVN. The two
>>concepts are: "update", with an optional revision number or date; and
>>"switch", with a tag or branch name, and -- again -- an optional
>>revision or date.
>>
>>
>
>But isn't "update" just a special case of "switch"? Can't you always
>substitute an "update" through a "switch"?
>
Dunno, but I'd guess yes.
>And then: should the user
>really care which command is used internally?
>
No.
>I think that on the
>User-Interface it would make very much sense to speak about
>"branches", "tags" and "revisions" and hide the "URLs" and
>"directories" that are used internally.
>
Ah, you can't do that. That's because we don't enforce a particular
branching scheme, so the GUI can't assume where the branches are stored.
For example: In the Subversion repository, we decided to have the
mainline on /trunk, branches in /branches, and tags in /tags. But
there's nothing in SVN that mandates that layout. At work, for instance,
I have the repo laid out like this:
/www
/proj1
/proj1
/dev
/main
/branch_1
/doc
/tag
All branches for proj1 are in /proj1/dev, with /proj1/dev/main being the
main branch. Tags for proj1 are copied from /proj1/dev into /proj1/tag.
The project web pages (/www) and project documentation (/proj1/doc) are
never branched. Technical documentation (i.e., our SVN's notes
directory) would go into /proj1/dev/main, and get branched as necessary.
> This is just because most
>people are already used to "branches" and "tags".
>Any opinions to such a proposal?
>
See above. You'd have to enforce a certain layout, and that would make
your GUI less than useful.
>I am not really sure whether I am too biased to CVS. I have made the
>expirience that it is very easy to explain new co-workers about
>branches and tags. I found it only hard to explain the sticky tags and
>the -A option that cvs use to implement moving withhin/across
>branches. So I think it would be good to inherit the branch notation.
>
It should be even easier to explain about directory copies. "If you want
to start an alternate line of development, just copy /proj1/dev/main
into /proj1/dev/some_descriptive_branch_name, and use `svn switch' to
move your working copy to that branch. Subversion will remember revision
history, and you'll be able to merge changes onto the mainline, etc. etc.)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 31 22:26:51 2002