On 13 Nov 2001 19:45:22 -0600
cmpilato@collab.net wrote:
...
> > svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
> > svn co http://foo.com/proj/branch
> > cd branch
> > # Make mods and mix revs
> > svn commit
>
> You can't easily make the mods and mix revisions here. I mean, let's
> put some numbers with your example:
>
> Say the head revision is 19.
>
> > svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
>
> Okay, so now there is a revision 20 with a copy of trunk.
>
> > svn co http://foo.com/proj/branch
>
> Now I have a working copy at revision 20, just of the branch.
>
> > cd branch
> > # Make mods and mix revs
> > svn commit
>
> Hm...mix revs. From what? Prior to revision 20, there was nothing in
> this particular portion of the source tree. Plus, now I've had to
> suffer an extraneous checkout (not an update, mind you) to get this
> done.
My mistake. I was thinking of creating a "branch" that had a couple
of files from an earlier revision.
touch f1.txt f2.txt
svn add f1.txt f2.txt
svn commit
echo f1 > f1.txt
echo f2 > f2.txt
svn commit
(assume that created rev 2)
svn update -r 1 f2.txt
svn commit
That does not make sense in the current implementation since there is
nothing to commit. Of course, it kind of reminds me of use case B
you cited:
svn cp -r 19 http://server/repos_path/to/foo.c foo.c
Would it be possible to this "bring back and old revision" operation via
update/commit instead of svn cp?
> > > Second, we have a new command: 'svn switch URL [-r rev]'
> >
> > Here is a wacky idea. How about we just avoid including this functionality?
> > Sure, it is possible to write code to do this, but perhaps we don't need to.
> > Why can't the user just go to a new directory and checkout a branch?
> > I really wonder if actual users are going to use this command much? There
> > is a non-zero cost associated with adding a new svn subcommand. We have
> > to document it and each user would have to learn what it does. My point is
> > that we should really have a good justification for each subcommand and
> > I am not sure this "change the URL of my WC update" is really that useful.
>
> Users will likely do this pretty regularly. Say I want to branch the
> tree so I work on some experimental code. I do my copy of .../trunk
> to .../branches/cmpilato-branch. Now, you're asking me to do a costly
> checkout (again, no diffs here, baby) just so I can download
> essentially *exactly* what I already have on disk!! Seriously, in
> this case, we'd like to be able to say, "Gee, the branch you're trying
> to convert your working copy to is exactly like the working copy you
> already have, except the stored URLs are different. Okay, we'll just
> update your URLs."
>
> Dude, you seriously need to come hang out with me on my 28.8 home
> network connection! :-)
Ok, that is a good point. We snotty DSL users tend to forget the bad old days :)
I am just not sure this special kind of update deserves its own subcommand.
I am not sure I like it, but what about something like this:
svn update --url=http://foo.bar/project/branch
P.S.
What about merges? How would one merge the changes from a given branch into
the HEAD?
cheers
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006