You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/11/13 22:31:22 UTC
M7: Branches and Tags
Last Friday, gstein flew to Chicago and {gstein, kfogel, cmpilato,
sussman, fitz} had a grand-old design and brainstorm session about how
to design the UI for branches, tags, merges, and so on. This mail
gives an overview of what we'd like to do for svn 0.7.
First, we want to make 'svn cp' into an all-powerful command:
We have four use cases for 'svn cp' now.
A. svn cp wc_path1 wc_path2
This duplicates a path in the working copy, and schedules it
for addition with history. (This is partially implemented in
0.6 already.)
B. svn cp URL [-r rev] wc_path
This "checks out" URL (in REV) into the working copy at
wc_path, integrates it, and schedules it for addition with
history.
C. svn cp wc_path URL
This immediately commits wc_path to URL on the server; the
commit will be an addition with history. The commit will not
change the working copy at all.
D. svn cp URL1 [-r rev] URL2
This causes a server-side copy to happen immediately; no
working copy is required.
[Note: we're using the phrase "tag" to mean "branch or tag"; they're
the same thing, and for now we're assuming that per-installation
administrative policy and/or ACLs will bother to differentiate. The
svn filesystem certainly doesn't.]
So how do I create a tag? Assume that the repository has a layout
like this:
/project1/trunk/
/project1/tags/
In the simplest case, if I want to tag the HEAD of trunk, I don't even
need a working copy. I use case (D) above:
svn cp http://foo.com/repos/project1/trunk \
http://foo.com/repos/project1/tags/milestone-6
Voila, no working copy needed. A "cheap" (constant-time) directory
copy is made on the server.
In a more complex case, suppose the state of my tree (mixed revisions
and all) is exactly what I want the tag to look like. In that case, I
use case (C):
cd top/of/my/wc
svn cp . http://foo.com/repos/project1/tags/milestone-6
I should mention that as a rule, cases (A) and (C) always notice mixed
revisions when committing.
Second, we have a new command: 'svn switch URL [-r rev]'
This command performs an update on your working copy, making it
reflect a new URL. This is how you "move" your working copy to a
branch or tag.
Really, 'svn up' is just a special case of 'svn switch', where the URL
is assumed to be the one you already have.
There's nothing magical about this command -- it will be fairly easy
to write, we hope; instead of calling svn_repos_dir_delta() on two
identical paths, the paths will be different now. The good news is
that _dir_delta doesn't care one bit. It examines node-rev-ids
anyway, and notices relationships between them. If, when updating
your working copy from a trunk to a branch, it discovers that 80% of
your files are already correct, then it won't send them. (However, if
you ask to switch your working copy to a completely unrelated URL,
then dir_delta probably *will* do something as extreme as removing and
re-checking out a new working copy.)
Also -- if the user has local mods that conflict with the switch, one
may very well get an 'obstructed update' error. An update is an
update, after all. Let the user beware; if she wants to switch her WC
to a branch cleanly, she should make sure her WC is clean to begin
with. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
re: Issue #525 (line-endings)
Posted by Bill Tutt <ra...@lyra.org>.
While working on the COM layer some more during this vacation week, I
discovered that the VB IDE requires correct Win32 line endings, and not
having them inserted correctly makes testing the COM layer changes more
difficult.
FYI,
Bill
--
Bunnies aren't just cute like everybody supposes.
They got their hoppy legs and twitchy little noses.
And what's with all the carrots,
What do they need such good eyesight for anyway?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Colin Putney <cp...@whistler.net>.
On Tuesday, November 20, 2001, at 03:25 PM, Mo DeJong wrote:
>>
>>> svn merge -r 150 subdir1
>>
>> Translating this command to English we get something like "merge the
>> changes that occurred between revision 1 and revision 150 in the
>> directory subdir1 into the working copy."
>
> Sorry, I meant "undo the changes made in subdir1/ between revs 150 and
> 200".
> That would let us create a branch that had older revisions of specific
> subdirectories
> or files in it. Perhaps it would be more clear as "snv merge
> CURRENT:150 subdir1",
> but I am not sure if there is a symbolic rev id that applies to the
> current revision.
I don't think that would work for you either. Remember that
/proj/branch/subdir1 was created at revision 200. So reversing that
change would mean deleting subdir1 from the working copy.
>>> svn merge -r 178:170 subdir2
>>
>> In this case, you will need a merge subcommand (since copying from
>> revisions 170 through 178 doesn't make sense), but "-r 178:170" will be
>> insufficient to specify what changes to merge into the working copy.
>> You'll need a URL so that svn can find the files:
>>
>> svn merge -r 178:170 http://foo.com/proj/trunk/subdir2 subdir2
>>
>> I guess in the case where http://foo.com/proj/branch *did* exist
>> between
>> r170 and r178 the URL could be omitted.
>
> I don't get that at all. The revision numbers apply to the whole tree
> right?
> A plain revision number should be enough info to merge backwards from
> a URL that was created with a copy command. I would agree that when
> you wanted to merge forward you would need to supply a URL and a
> revision to merge to.
Again, /proj/branch/subdir2 didn't exist between r170 and r178, so
reversing those transactions wouldn't do anything.
What you wanted, I think, was to get the changes to /proj/trunk/subdir2
between170 and 178, and apply them in reverse to the working copy. But
since the working copy's ancestor is http://foo.com/proj/branch, you
need to supply the URL to make that happen. Remember /proj/branch really
is a copy of /proj/trunk, not a symlink or something.
> Here is a quick example:
>
> (assume we checked out .../HEAD)
> svn cp project branch
> svn commit -m "created branch" branch
> cd branch
> (create foo.c and bar.c)
> svn add foo.c bar.c
> svn commit foo.c bar.c -m "added foo.c and bar.c on branch"
>
> Assume the initial rev was 9, before we added the branch dir.
> We added the branch subdir and that created rev 10.
> We then added foo.c and bar.c and that created rev 11.
> Then we go off and do a bunch of other commits and
> end up at revision 50 for the whole tree.
>
> What I am saying is that I should be able to go into a
> subdir and "undo" some changes to a specific file
> or directory. Like so:
>
> cd branch
> svn merge -r 50:9 bar.c
Ok, sure. I suspect that the merge command will let you do just that,
when it gets implemented. On the other hand, if you wanted to get rid of
bar.c, you could just do this:
svn rm bar.c
Surely that's simpler than digging through the commit logs to see where
bar.c was added and then reversing that commit?
> That should schedule bar.c for removal, just the opposite
> of the commands that added bar.c during the transition
> from state 10 -> 11. The .svn/entries file will have
> an ancestor=$URL entry, so the system should know
> I am talking about $URL/bar.c here. I don't see why
> I would need to give the fully qualified URL here (ala case B).
Yup, in this scenario, you wouldn't need the URL.
>> So basically I'm saying that you do need a copy command with all
>> permutations of wc paths and URLs in its operands. The fact that CVS
>> requires you to do a merge to accomplish the same task doesn't imply
>> that svn's copy command does a merge.
>
> That sure seems like a merge to me. I am not saying there is no use for
> case B, just that the example of recovering a deleted file by reverting
> to an earlier revision does not seem like a "copy" operation.
It depends on how you look at it. The situation is that you need to
create a certain file with certain data in it. You know that the file
existed in the past. One way to get it back is to "undo" the deletion of
the file. Another way is to copy it out of the past into the present.
Either way, you get the file back.
Strictly speaking, you only need use case A of the copy command. In all
cases, you can check out the entire repository, do a copy-with-history
in your working copy and commit. But that can be a fairly expensive
operation, in terms of bandwidth, local disk space, time, and user
keystrokes. So allowing copies to and from URLs is a big win.
At the same time, I contend that 'svn cp' is a much better user
interface than 'svn merge'. Copying is a very well defined operation and
easy to understand. Imagine doing development without the benefit of
software that handles versioning automatically. You'd do it all with
copies - making "backups" of the source tree at various stages of
development that you might want to go back and look at. Subversion just
makes the storage of all those copies efficient and provides some tools
for examining the relationships between copies.
A merge is a more complicated operation. It is necessary for some of the
strange things we sometimes need to do with version control, but it's
fundamentally less intuitive than a copy. CVS uses merges for
everything, but that's because CVS can't do copies. I think the merge
command in Subversion should be narrower in scope, and used only when a
merge is truly necessary, like reintegrating branches into the main line
of development.
Cheers,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Mo DeJong <su...@bayarea.net>.
...
> > The restore a deleted file operation could be accomplished like so:
> >
> > % svn rm one
> > % svn commit one
> >
> > (assume the commit created rev 2)
> >
> > % svn merge -r 2:1 one
> > % svn commit one
> >
> > Doesn't that seem a whole lot cleaner that use case B?
>
> I agree that some type of merge command will probably be necessary, but
> I think this is a different operation than a copy.
...
>That doesn't imply that merge behavior gets mixed in with copies.
Well, I think we are agreed that copy and merge are different things.
What I am saying is that case B as outlined is really just a merge to
an earlier revision (before the file got deleted). I am not talking about
how it is implemented, rather how it is presented to the user.
...
> > It seems like this is yet another place where a merge command could
> > be very useful. Assume we had a merge command and used it along with
> > the switch subcommand to create a new branch and then mix in some older
> > revs in the new branch. The following could be done instead of use
> > case C.
> >
> > svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
> > svn switch http://foo.com/proj/branch
>
> This is a perfect example of what cmpilato (I think...) was talking
> about. Let's assume that the copy in the example above creates revision
> 200.
>
> > svn merge -r 150 subdir1
>
> Translating this command to English we get something like "merge the
> changes that occurred between revision 1 and revision 150 in the
> directory subdir1 into the working copy."
Sorry, I meant "undo the changes made in subdir1/ between revs 150 and 200".
That would let us create a branch that had older revisions of specific subdirectories
or files in it. Perhaps it would be more clear as "snv merge CURRENT:150 subdir1",
but I am not sure if there is a symbolic rev id that applies to the current revision.
...
> > svn merge -r 178:170 subdir2
>
> In this case, you will need a merge subcommand (since copying from
> revisions 170 through 178 doesn't make sense), but "-r 178:170" will be
> insufficient to specify what changes to merge into the working copy.
> You'll need a URL so that svn can find the files:
>
> svn merge -r 178:170 http://foo.com/proj/trunk/subdir2 subdir2
>
> I guess in the case where http://foo.com/proj/branch *did* exist between
> r170 and r178 the URL could be omitted.
I don't get that at all. The revision numbers apply to the whole tree right?
A plain revision number should be enough info to merge backwards from
a URL that was created with a copy command. I would agree that when
you wanted to merge forward you would need to supply a URL and a
revision to merge to.
Here is a quick example:
(assume we checked out .../HEAD)
svn cp project branch
svn commit -m "created branch" branch
cd branch
(create foo.c and bar.c)
svn add foo.c bar.c
svn commit foo.c bar.c -m "added foo.c and bar.c on branch"
Assume the initial rev was 9, before we added the branch dir.
We added the branch subdir and that created rev 10.
We then added foo.c and bar.c and that created rev 11.
Then we go off and do a bunch of other commits and
end up at revision 50 for the whole tree.
What I am saying is that I should be able to go into a
subdir and "undo" some changes to a specific file
or directory. Like so:
cd branch
svn merge -r 50:9 bar.c
That should schedule bar.c for removal, just the opposite
of the commands that added bar.c during the transition
from state 10 -> 11. The .svn/entries file will have
an ancestor=$URL entry, so the system should know
I am talking about $URL/bar.c here. I don't see why
I would need to give the fully qualified URL here (ala case B).
> So basically I'm saying that you do need a copy command with all
> permutations of wc paths and URLs in its operands. The fact that CVS
> requires you to do a merge to accomplish the same task doesn't imply
> that svn's copy command does a merge.
That sure seems like a merge to me. I am not saying there is no use for
case B, just that the example of recovering a deleted file by reverting
to an earlier revision does not seem like a "copy" operation.
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Ben Collins-Sussman <su...@collab.net>.
Colin Putney <cp...@whistler.net> writes:
> So basically I'm saying that you do need a copy command with all
> permutations of wc paths and URLs in its operands. The fact that CVS
> requires you to do a merge to accomplish the same task doesn't imply
> that svn's copy command does a merge.
Gee whiz, I was in the middle of writing up a very similar
response... you beat me to it. I agree exactly. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Colin Putney <cp...@whistler.net>.
cmpilato@collab.net gave the following scenario as an example of use
case B for 'svn cp':
>> Say I have a working copy, up-to-date with the head revision (which is
>> 19). I also have a file, foo.c, which I decide to delete.
>>
>> `svn rm foo.c` # schedule foo.c for deletion
>> `svn ci` # commit the deletion of foo.c, now repos is rev. 20
>>
>> Time (and revision history) goes by, and oh, crud. I just remembered
>> that I actually *needed* that file. No problem, just restore it, and
>> continue history from where it left off.
>>
>> `svn cp -r 19 http://server/repos_path/to/foo.c` foo.c
>>
>> Now, I have a working copy with foo.c back in it, scheduled for
>> addition. When I commit, I have essentially restored foo.c from where
>> it left off.
On Monday, November 19, 2001, at 04:32 AM, Mo DeJong countered with the
idea of accomplishing the same task with a merge subcommand:
> I thought about this some more and I realized why this
> operation was bothering me so much, it mixes merge
> behavior in with the cp command. This seems like yet
> another example of the "super command" fever that
> has swept the list of late.
>
> This restore a deleted file operation would be
> a reverse double -j merge in CVS. Here is a quick
> example:
[ snip example]
> Now, I know we are not supposed to talk about merges until the
> next release is done, but since it seems the copy command would
> be doing merge like things we should address this now. I don't
> have a problem with the functionality, I just care about how
> it is presented to the user.
>
> I claim that merging should have its own subcommand. We should
> not repeat the mistake of cvs by overloading some other
> subcommand.
>
> The subcommand usage might look like:
>
> svn merge [URL] [-r rev] [wc_path]
>
> One might merge changes from a branch named "mybranch" like so:
>
> % svn merge $URL/mybranch
>
> The restore a deleted file operation could be accomplished like so:
>
> % svn rm one
> % svn commit one
>
> (assume the commit created rev 2)
>
> % svn merge -r 2:1 one
> % svn commit one
>
> Doesn't that seem a whole lot cleaner that use case B?
I agree that some type of merge command will probably be necessary, but
I think this is a different operation than a copy. Because Subversion
relies on copies to do branching and tagging, you need a general,
flexible copy primitive in order to be able to take full advantage of
the revision history available in the repository. CVS uses a different
tagging and branching model, so tasks that require a merge in CVS might
not in Subversion simply because that copy primitive is, in fact,
available. That doesn't imply that merge behavior gets mixed in with
copies.
>>> 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.
>
>
> It seems like this is yet another place where a merge command could
> be very useful. Assume we had a merge command and used it along with
> the switch subcommand to create a new branch and then mix in some older
> revs in the new branch. The following could be done instead of use
> case C.
>
> svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
> svn switch http://foo.com/proj/branch
This is a perfect example of what cmpilato (I think...) was talking
about. Let's assume that the copy in the example above creates revision
200.
> svn merge -r 150 subdir1
Translating this command to English we get something like "merge the
changes that occurred between revision 1 and revision 150 in the
directory subdir1 into the working copy." But that's revision 150 of
what? Remember that the working copy reflects
http://foo.com/proj/branch. And since http://foo.com/proj/branch/subdir1
was created at r200, it didn't exist at r150. In order to accomplish
this, you'll need to do a copy:
svn cp -r 150 http://foo.com/proj/trunk/subdir1 subdir1
This is use case B.
> svn merge -r 178:170 subdir2
In this case, you will need a merge subcommand (since copying from
revisions 170 through 178 doesn't make sense), but "-r 178:170" will be
insufficient to specify what changes to merge into the working copy.
You'll need a URL so that svn can find the files:
svn merge -r 178:170 http://foo.com/proj/trunk/subdir2 subdir2
I guess in the case where http://foo.com/proj/branch *did* exist between
r170 and r178 the URL could be omitted.
> svn commit -m "created new mixed rev branch"
So basically I'm saying that you do need a copy command with all
permutations of wc paths and URLs in its operands. The fact that CVS
requires you to do a merge to accomplish the same task doesn't imply
that svn's copy command does a merge.
Cheers,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Mo DeJong <su...@bayarea.net>.
On 13 Nov 2001 19:45:22 -0600
cmpilato@collab.net wrote:
> > > B. svn cp URL [-r rev] wc_path
> > >
> > > This "checks out" URL (in REV) into the working copy at
> > > wc_path, integrates it, and schedules it for addition with
> > > history.
> >
> > Humm, I have to admit I don't get it. Could you describe how case
> > B would actually be used? Is this how users are expected to merge
> > changes from another branch into the WC?
>
> Say I have a working copy, up-to-date with the head revision (which is
> 19). I also have a file, foo.c, which I decide to delete.
>
> `svn rm foo.c` # schedule foo.c for deletion
> `svn ci` # commit the deletion of foo.c, now repos is rev. 20
>
> Time (and revision history) goes by, and oh, crud. I just remembered
> that I actually *needed* that file. No problem, just restore it, and
> continue history from where it left off.
>
> `svn cp -r 19 http://server/repos_path/to/foo.c` foo.c
>
> Now, I have a working copy with foo.c back in it, scheduled for
> addition. When I commit, I have essentially restored foo.c from where
> it left off.
I thought about this some more and I realized why this
operation was bothering me so much, it mixes merge
behavior in with the cp command. This seems like yet
another example of the "super command" fever that
has swept the list of late.
This restore a deleted file operation would be
a reverse double -j merge in CVS. Here is a quick
example:
% echo 1 > one
% cvs add one
% cvs commit -m "" one
% rm one
% cvs rm one
% cvs commit -m "" one
Now to get the file back from its dead state. Assume
that the above checking created revisions 1.1 and 1.2.
% cvs update -j 1.2 -j 1.1 one
U one
% cvs up
A one
% cvs diff one
Index: one
===================================================================
RCS file: one
diff -N one
--- /dev/null Tue May 5 13:32:27 1998
+++ one Mon Nov 19 03:42:58 2001
@@ -0,0 +1 @@
+1
% cvs commit -m "restored file one" one
Now, I know we are not supposed to talk about merges until the
next release is done, but since it seems the copy command would
be doing merge like things we should address this now. I don't
have a problem with the functionality, I just care about how
it is presented to the user.
I claim that merging should have its own subcommand. We should
not repeat the mistake of cvs by overloading some other
subcommand.
The subcommand usage might look like:
svn merge [URL] [-r rev] [wc_path]
One might merge changes from a branch named "mybranch" like so:
% svn merge $URL/mybranch
The restore a deleted file operation could be accomplished like so:
% svn rm one
% svn commit one
(assume the commit created rev 2)
% svn merge -r 2:1 one
% svn commit one
Doesn't that seem a whole lot cleaner that use case B?
> > 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.
It seems like this is yet another place where a merge command could
be very useful. Assume we had a merge command and used it along with
the switch subcommand to create a new branch and then mix in some older
revs in the new branch. The following could be done instead of use
case C.
svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
svn switch http://foo.com/proj/branch
svn merge -r 150 subdir1
svn merge -r 178:170 subdir2
svn commit -m "created new mixed rev branch"
The above would not require an extra checkout and it could
provide the same functionality. The real benefit of this is
that the cp command would not have a "special case" where it
would also do a commit behind the scenes. The cp command
would only need to support use cases A and D.
cheers
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>Mo DeJong <su...@bayarea.net> writes:
>
>>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
>>
>
>We did talk about update becoming sort of an supercommand. Given the
>usage:
>
> svn update SRC-URL WC-TGT
>
>- If SRC is missing, it's a regular update.
>- If WC-TGT is missing (or doesn't represent an actual working copy
> yet), this is a checkout
>- If both are missing, WC-TGT is an implied '.', so see the above for
> what happens.
>- If neither is missing, this is basically the 'switch' command.
>
>Thoughts?
>
GregS, Ben and I chatted on irc last night about having a "svn fetch"
command that would encapsulate checkout, update and switch (these would
become mere aliases). I think we found (and solved) most of the edge cases.
Greg promised to write up our conclusions and post here. Greg?
--
Brane �ibej <br...@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
Re: M7: Branches and Tags
Posted by cm...@collab.net.
Mo DeJong <su...@bayarea.net> writes:
> > 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 :)
Hehheh.
> 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
We did talk about update becoming sort of an supercommand. Given the
usage:
svn update SRC-URL WC-TGT
- If SRC is missing, it's a regular update.
- If WC-TGT is missing (or doesn't represent an actual working copy
yet), this is a checkout
- If both are missing, WC-TGT is an implied '.', so see the above for
what happens.
- If neither is missing, this is basically the 'switch' command.
Thoughts?
> What about merges? How would one merge the changes from a given branch into
> the HEAD?
You're not allowed to talk about merges until after M7 is done. Merge
is in M8. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Mo DeJong <su...@bayarea.net>.
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
Re: M7: Branches and Tags
Posted by cm...@collab.net.
Mo DeJong <su...@bayarea.net> writes:
> Uhh, you are scaring me a little. All powerfull commands are not
> necessarily a good thing.
Don't sweat it. If you want to write a wrapper script to hide the
power, you're welcome to do so. :-)
> > B. svn cp URL [-r rev] wc_path
> >
> > This "checks out" URL (in REV) into the working copy at
> > wc_path, integrates it, and schedules it for addition with
> > history.
>
> Humm, I have to admit I don't get it. Could you describe how case
> B would actually be used? Is this how users are expected to merge
> changes from another branch into the WC?
Say I have a working copy, up-to-date with the head revision (which is
19). I also have a file, foo.c, which I decide to delete.
`svn rm foo.c` # schedule foo.c for deletion
`svn ci` # commit the deletion of foo.c, now repos is rev. 20
Time (and revision history) goes by, and oh, crud. I just remembered
that I actually *needed* that file. No problem, just restore it, and
continue history from where it left off.
`svn cp -r 19 http://server/repos_path/to/foo.c` foo.c
Now, I have a working copy with foo.c back in it, scheduled for
addition. When I commit, I have essentially restored foo.c from where
it left off.
> 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.
> > 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! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Mo DeJong <su...@bayarea.net>.
On 13 Nov 2001 16:31:22 -0600
Ben Collins-Sussman <su...@collab.net> wrote:
> Last Friday, gstein flew to Chicago and {gstein, kfogel, cmpilato,
> sussman, fitz} had a grand-old design and brainstorm session about how
> to design the UI for branches, tags, merges, and so on. This mail
> gives an overview of what we'd like to do for svn 0.7.
>
> First, we want to make 'svn cp' into an all-powerful command:
Uhh, you are scaring me a little. All powerfull commands are not
necessarily a good thing.
> B. svn cp URL [-r rev] wc_path
>
> This "checks out" URL (in REV) into the working copy at
> wc_path, integrates it, and schedules it for addition with
> history.
Humm, I have to admit I don't get it. Could you describe how case
B would actually be used? Is this how users are expected to merge
changes from another branch into the WC?
> C. svn cp wc_path URL
>
> This immediately commits wc_path to URL on the server; the
> commit will be an addition with history. The commit will not
> change the working copy at all.
...
> In a more complex case, suppose the state of my tree (mixed revisions
> and all) is exactly what I want the tag to look like. In that case, I
> use case (C):
>
> cd top/of/my/wc
> svn cp . http://foo.com/repos/project1/tags/milestone-6
I don't like this at all. Why should there be any way to commit things
to the repo without using the commit command? Can't we get the
same functionality using D, cp first and then commit the changes?
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
> Second, we have a new command: 'svn switch URL [-r rev]'
>
> This command performs an update on your working copy, making it
> reflect a new URL. This is how you "move" your working copy to a
> branch or tag.
>
> Really, 'svn up' is just a special case of 'svn switch', where the URL
> is assumed to be the one you already have.
>
> There's nothing magical about this command -- it will be fairly easy
> to write, we hope; instead of calling svn_repos_dir_delta() on two
> identical paths, the paths will be different now. The good news is
> that _dir_delta doesn't care one bit. It examines node-rev-ids
> anyway, and notices relationships between them. If, when updating
> your working copy from a trunk to a branch, it discovers that 80% of
> your files are already correct, then it won't send them. (However, if
> you ask to switch your working copy to a completely unrelated URL,
> then dir_delta probably *will* do something as extreme as removing and
> re-checking out a new working copy.)
>
> Also -- if the user has local mods that conflict with the switch, one
> may very well get an 'obstructed update' error. An update is an
> update, after all. Let the user beware; if she wants to switch her WC
> to a branch cleanly, she should make sure her WC is clean to begin
> with. :-)
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.
cheers
Mo DeJong
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Bruce Atherton <br...@callenish.com>.
At 12:09 PM 11/15/2001 -0800, Greg Stein wrote:
>You can do that today:
>
> $ svn cp trunk tags/mytag1
> $ svn commit
Again, this does not address the situation. Let me try to explain another way.
What do people use tags for in CVS? Personally, I have used them in 4 ways.
1. To mark revisions that go into a release. You guys have been
targeting this, and I agree that the solution proposed works well.
2. To create branches. Ditto.
3. To mark files in some way that an external system can use as metadata
about the file. I've marked files that a Java build system should run an
RMI compiler on, for example. Properties will undoubtedly work fine here.
4. To do code promotion. This is the use where I'm seeing the svn cp
command being a solution, but not a very good one. Code promotion at the QA
level, which will typically be promoting entire trees, will work fine. But
at the Developer level where promotion occurs constantly on individual
files, it is a disaster.
>Since tags are just copies between directories, we don't want to enforce
>specific directory structures within the core code.
Understood. Any solution would have to be generic enough to apply anywhere
(such as the string replace I mentioned), although it would probably make
sense to include a best-practices document that showed a few setups that
were considered good ones, perhaps with supporting scripts and/or
configuration files. But I digress.
>"Tags" are copies. That is defined and closed :-)
Of course.
>How that copy is performed is up to discussion. And to some extent, it is a
>bikeshed. But all "user model" / "user interface" discussions are bikesheds
>for the most part. The hard part is figuring out the model/interface that is
>easiest and most intuitive.
I agree, and that is why I made that comment about dropping it. But somehow
the commands supported by the svn command line client "feel" more
fundamental than just a user interface issue. Perhaps it is because of the
way that the CVS command line client interface has defined all GUIs that
came afterwards, which hopefully won't be as much of a problem with
Subversion and its API for clients. Still, it feels to me like the command
line client will provide a way of thinking about the repository/working
copy relationship that will impact most clients that follow. That's the
reason I brought this whole thing up now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Colin Putney <cp...@whistler.com>.
On Friday, November 16, 2001, at 10:05 AM, Bruce Atherton wrote:
> At 09:22 AM 11/16/2001 -0500, Kevin Pilch-Bisson wrote:
>> I think the issue is that most of the svn developers have been
>> concerned with
>> branching/tagging a whole project, whereas Bruce wants an easy way to
>> tag a
>> single file, without typing that files path in the tags area.
>>
>> Now maybe the way to do this is to just always branch/tag the whole
>> project
>> (since it doesn't take up any extra space/time).
>
> This is a very interesting idea, but I can see a few problems with it.
>
> First of all, it assumes that everything in your working copy is ready
> to be promoted. This is often not the case, and will almost certainly
> result in developers getting very confused about files "mysteriously"
> getting tagged.
>
> Secondly, I don't think it would play well with other developers
> changes. You would essentially be saying that all files in your working
> copy are ready to be promoted, including those being worked on by
> somebody else. They might not be too happy about that.
I think the real issue here is the whole notion of tags.
Tags are a CVS thing. Their purpose is to establish which revisions of a
set of files correspond to each other, since CVS keeps revisions per
file. Subversion doesn't need tags because the revision numbers reflect
the state of the entire repository. The "copy solution" that always gets
mentioned is actually unnecessary, since all you really need to do is
remember the revision number you're interested in. The copy just makes
that revision "stand out" a bit because you can see it in a directory
listing and give it a name instead of a number. The real power of 'svn
cp' is for branching.
Of course, CVS tags are a general mechanism and useful for other things,
like code promotion. But I think a better mechanism to accomplish the
same task is Subversion properties. After all, CVS tags are basically
properties that only take boolean values. I'd be pretty easy to do
integration testing as Bruce describes by agreeing on a property name
("qa:quality" for example) and values ("INTEG", "PREQA", "QA",
"RELEASE").
The key is to make it easy to find files or directories with given
properties using the svn client.
Colin
PS. By way of introduction, I've just joined the subversion project as
an Observer. I use CVS a lot, and love it, but curse it regularly. I
really like the way subversion is shaping up, and hope to make some
contributions in the near future.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Nov 16, 2001 at 10:05:29AM -0800, Bruce Atherton wrote:
> At 09:22 AM 11/16/2001 -0500, Kevin Pilch-Bisson wrote:
>...
> >Now maybe the way to do this is to just always branch/tag the whole project
> >(since it doesn't take up any extra space/time).
>
> This is a very interesting idea, but I can see a few problems with it.
>
> First of all, it assumes that everything in your working copy is ready to
> be promoted. This is often not the case, and will almost certainly result
> in developers getting very confused about files "mysteriously" getting tagged.
>
> Secondly, I don't think it would play well with other developers changes.
> You would essentially be saying that all files in your working copy are
> ready to be promoted, including those being worked on by somebody else.
> They might not be too happy about that.
In your particular scenario, I could see the following tree layout:
/
trunk/
integ/
bruce/
john/
jane/
integ/ is a copy of trunk/. Whenever you want to release a file(s) for
integration, you copy it over to integ/bruce/ and commit that change. Your
integration team merges changes from the integ/ area into trunk/
Does that work the same as today? Nope. Does it make sense for your
particular scenario? Can't really say. But it is a first pass. I'm sure you
can refine it.
Basically: to tag individual files, just copy them into a "tag area".
I think about the only real conclusion to this thread is to say that SVN has
its definition of tagging. Let's see how people will work with that model,
what kinds of tools people will ask for and develop, and we can go from
there. The copy model is a lot better than CVS's model for a number of
reasons, but is quite different. Maybe it will fall down in a particular
scenario where CVS succeeds. Oh well... we rock in so many other areas that
I'm not too concerned :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Bruce Atherton <br...@callenish.com>.
At 09:22 AM 11/16/2001 -0500, Kevin Pilch-Bisson wrote:
>I think the issue is that most of the svn developers have been concerned with
>branching/tagging a whole project, whereas Bruce wants an easy way to tag a
>single file, without typing that files path in the tags area.
>
>Now maybe the way to do this is to just always branch/tag the whole project
>(since it doesn't take up any extra space/time).
This is a very interesting idea, but I can see a few problems with it.
First of all, it assumes that everything in your working copy is ready to
be promoted. This is often not the case, and will almost certainly result
in developers getting very confused about files "mysteriously" getting tagged.
Secondly, I don't think it would play well with other developers changes.
You would essentially be saying that all files in your working copy are
ready to be promoted, including those being worked on by somebody else.
They might not be too happy about that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Nov 16, 2001 at 09:22:33AM -0500, Kevin Pilch-Bisson wrote:
>...
> eg:
>
> $ cd <top of tree>/trunk
> $ svn cp . http://some.server.com/repos/tags/mytag1
> $ svn switch http://some.server.com/repos/tags/mytag1
>
> Although this is still far more typing than:
>
> cvs tag filename.
Write a shell script, then.
And note that your "switch" is different behavior than cvs tag. The cvs
command doesn't add a sticky tag to your WC.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Nov 15, 2001 at 12:09:03PM -0800, Greg Stein wrote:
> On Thu, Nov 15, 2001 at 09:43:32AM -0800, Bruce Atherton wrote:
> > At 09:40 PM 11/14/2001 -0600, Ben Collins-Sussman wrote:
> >
> > >So, in your ideal world, it would be possible to type
> > >
> > > $ svn cp . mytag1
> > >
> > >And voila, your mixed-revision working copy magically appears in some
> > >'automatic' tags-area on the server?
> > >(i.e. http://foo.com/repos/tags/mytag1 is created)
> >
> > Yes, something like that. I'm not concerned with exactly how it is
> > accomplished, I just think it should be easy for those environments where
> > it is a common action.
>
> You can do that today:
>
> $ svn cp trunk tags/mytag1
> $ svn commit
>
> That is awfully simple to me. Ben just gave an example using a URL. The URL
> form avoids the disk copy associated with the above command (a copy within
> the working copy will make a disk copy).
I think the issue is that most of the svn developers have been concerned with
branching/tagging a whole project, whereas Bruce wants an easy way to tag a
single file, without typing that files path in the tags area.
Now maybe the way to do this is to just always branch/tag the whole project
(since it doesn't take up any extra space/time).
eg:
$ cd <top of tree>/trunk
$ svn cp . http://some.server.com/repos/tags/mytag1
$ svn switch http://some.server.com/repos/tags/mytag1
Although this is still far more typing than:
cvs tag filename.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: M7: Branches and Tags
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 15, 2001 at 09:43:32AM -0800, Bruce Atherton wrote:
> At 09:40 PM 11/14/2001 -0600, Ben Collins-Sussman wrote:
>...
> >Wow. Hm. I wonder if more experienced CVS users on this list can
> >address your use-case better. Perhaps properties are what you want,
> >as you say... Subversion doesn't "tag" files the way RCS does; all
> >you can do is make cheap copies on the server.
>
> Yes, and I presume there wouldn't be nearly as much overhead in setting a
> property on a particular set of files/revisions.
Properties are more expensive than copies.
> >So, in your ideal world, it would be possible to type
> >
> > $ svn cp . mytag1
> >
> >And voila, your mixed-revision working copy magically appears in some
> >'automatic' tags-area on the server?
> >(i.e. http://foo.com/repos/tags/mytag1 is created)
>
> Yes, something like that. I'm not concerned with exactly how it is
> accomplished, I just think it should be easy for those environments where
> it is a common action.
You can do that today:
$ svn cp trunk tags/mytag1
$ svn commit
That is awfully simple to me. Ben just gave an example using a URL. The URL
form avoids the disk copy associated with the above command (a copy within
the working copy will make a disk copy).
> >My only comment on this is that perhaps that the "default" tags path
> >can live in an .svnrc?
>
> That is somewhat complicated by the fact that the recommended tags
> directory is kept per project, which means there is no single default tags
> path.
You could have per-project defaults in the .svnrc ... but the point is still
valid.
> That's why I suggested a replacement on a portion of the URL. Then
> there is the issue of tags on branches. Since branches are essentially tag
> directories that can be committed against, there has to be support in
> Subversion for tags within tags, and I'm not clear on exactly how a .svnrc
> file can provide that.
Since tags are just copies between directories, we don't want to enforce
specific directory structures within the core code.
> In any case, the reason I brought this up is because I saw problems with
> the current "svn cp" concept for tagging. If you guys think that the best
> solution to this problem is to throw a layer over top of the current design
> rather than reworking it, then this becomes a bikeshed issue and I'll drop
> it for now.
"Tags" are copies. That is defined and closed :-)
How that copy is performed is up to discussion. And to some extent, it is a
bikeshed. But all "user model" / "user interface" discussions are bikesheds
for the most part. The hard part is figuring out the model/interface that is
easiest and most intuitive.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Bruce Atherton <br...@callenish.com>.
At 09:40 PM 11/14/2001 -0600, Ben Collins-Sussman wrote:
>Wow. Hm. I wonder if more experienced CVS users on this list can
>address your use-case better. Perhaps properties are what you want,
>as you say... Subversion doesn't "tag" files the way RCS does; all
>you can do is make cheap copies on the server.
Yes, and I presume there wouldn't be nearly as much overhead in setting a
property on a particular set of files/revisions.
>So, in your ideal world, it would be possible to type
>
> $ svn cp . mytag1
>
>And voila, your mixed-revision working copy magically appears in some
>'automatic' tags-area on the server?
>(i.e. http://foo.com/repos/tags/mytag1 is created)
Yes, something like that. I'm not concerned with exactly how it is
accomplished, I just think it should be easy for those environments where
it is a common action.
>My only comment on this is that perhaps that the "default" tags path
>can live in an .svnrc?
That is somewhat complicated by the fact that the recommended tags
directory is kept per project, which means there is no single default tags
path. That's why I suggested a replacement on a portion of the URL. Then
there is the issue of tags on branches. Since branches are essentially tag
directories that can be committed against, there has to be support in
Subversion for tags within tags, and I'm not clear on exactly how a .svnrc
file can provide that.
In any case, the reason I brought this up is because I saw problems with
the current "svn cp" concept for tagging. If you guys think that the best
solution to this problem is to throw a layer over top of the current design
rather than reworking it, then this becomes a bikeshed issue and I'll drop
it for now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Ben Collins-Sussman <su...@collab.net>.
Bruce Atherton <br...@callenish.com> writes:
> Now, perhaps the problem is that I am not really "getting" the brave
> new world, that rather than using tags for code promotion in
> Subversion we should be using properties or something similar. Or
> perhaps there really is a simpler way to specify the tag directory
> mapping using the cp command than I am realizing.
Wow. Hm. I wonder if more experienced CVS users on this list can
address your use-case better. Perhaps properties are what you want,
as you say... Subversion doesn't "tag" files the way RCS does; all
you can do is make cheap copies on the server.
>
> All I'm saying is that I believe it would be quite desirable if the
> solution for tagging that Subversion ended up with did not force so
> much typing, since there are environments where it happens frequently.
So, in your ideal world, it would be possible to type
$ svn cp . mytag1
And voila, your mixed-revision working copy magically appears in some
'automatic' tags-area on the server?
(i.e. http://foo.com/repos/tags/mytag1 is created)
My only comment on this is that perhaps that the "default" tags path
can live in an .svnrc?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Bruce Atherton <br...@callenish.com>.
At 06:30 PM 11/14/2001 -0600, Ben Collins-Sussman wrote:
>Bruce Atherton <br...@callenish.com> writes:
> > If I understand you correctly, though, if you want to move a tag deep
> > in your wc, you have to do something like this:
>
>Nope, I think you're confused.
Well that wouldn't be much of a surprise, and I'd be glad to learn that I
was. But what you tell me below doesn't enlighten me as to where my
confusion lies.
>If I want to tag some really deep directory in my working copy, I
>don't need to cd in there at all. It's optional. I can just specify
>the deep wc path as the first argument to 'svn cp', or I can cd in and
>specify '.' as the first argument. There's no difference.
Sorry, I wasn't suggesting that you HAD to. I was just using the current
directory to illustrate a point.
With CVS, there is a real benefit to being in that directory (which a
developer who is working on this code is likely to be doing anyway). The
reason is that the CVS/Repository file keeps track of how that directory in
the working copy maps to a directory in the repository. Because of that, I
can simply type:
cvs tag -F MYTAG myfile
no matter where I am in my working copy, and I know the correct file and
revision will get that tag. This is very convenient, and far less error
prone than trying to specify the tag using the CVS rtag command, which
ignores your working copy entirely:
cvs rtag -F MYTAG some/really/deep/directory/path/I/am/using/myfile
Now, it appears to me that the tagging solution offered by the svn cp
command is always going to look a whole lot more like rtag than tag, which
really would be a usability problem. This is happening because the mapping
back to the repository that happens in .svn/dir-wcprops or .svn/entries (I
haven't looked at the code to determine which) is not mapping to both the
original location AND some equivalent location within the tags directory.
Nor does the client have any clue (by design) as to how to perform the
mapping automatically.
>Secondly, I can "copy" my wc directory to any location I want on the
>server. The 2nd argument can be any old URL I want, shallow or deep.
>It just depends on how I've laid out the server. Remember, a tag is
>just an ordinary directory in the repository filesystem -- it could go
>anywhere. (If this is news to you, read the design spec, or the end
>of the "SVN for CVS users" doc.)
No, not news at all, but I don't see how that will deal with the issue I am
raising. I'm not talking about tagging a tree of the files in a release,
I'm talking about tagging files individually or by directory. And the
flexibility you are talking about is not going to be a benefit for
developers who tag files regularly, in a systematic way, many times a day.
Let me give you a use case that I believe is probably pretty common,
perhaps that will help.
You are working with a team of developers who have two tags at their
disposal (three if you include HEAD). They check out some small portion of
code to work with, and when they have tested it enough on their sandbox
they tag it as being ready for integration testing, say with the INTEG tag.
Any file with the INTEG tag gets automatically checked out and built on an
integration machine and the results stored on a shared drive that every
developer uses (their local code overrides the shared code, if present).
Agile Methodologies often use this type of rapid integration, for example.
When the developer considers a set of their changes to be feature complete
and ready to go into production (passing through QA first, of course), they
put a PREQA tag on the revisions that are tagged INTEG. After this point
the release manager decides whether it actually is going into production
and assigns a tag reflecting the release number.
As is all too often the case, QA finds a bug that must be fixed before the
code can be promoted. Fortunately, the fix is easy. The developer goes into
their working copy, makes the change, and tags the file INTEG.
Unfortunately, in order to tag the file so it can go back through the
promotion scheme, he has to type a phenomenally long string to make that
happen, perhaps several times for different files. And if the integration
build is successful, do the same thing over again to tag it PREQA. This is
a pretty big burden if you are fixing dozens of small bugs in a day, larger
than fixing the bugs themselves. I sure wouldn't want to do it.
Now, perhaps the problem is that I am not really "getting" the brave new
world, that rather than using tags for code promotion in Subversion we
should be using properties or something similar. Or perhaps there really is
a simpler way to specify the tag directory mapping using the cp command
than I am realizing.
All I'm saying is that I believe it would be quite desirable if the
solution for tagging that Subversion ended up with did not force so much
typing, since there are environments where it happens frequently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Ben Collins-Sussman <su...@collab.net>.
Bruce Atherton <br...@callenish.com> writes:
> At 04:31 PM 11/13/2001 -0600, Ben Collins-Sussman wrote:
> > cd top/of/my/wc
> > svn cp . http://foo.com/repos/project1/tags/milestone-6
>
> If I understand you correctly, though, if you want to move a tag deep
> in your wc, you have to do something like this:
>
> cd top/of/my/wc/some/really/deep/directory/path/I/am/using
> svn cp
> .
> http://foo.com/repos/project1/tags/milestone-6/some/really/deep/directory/path/I/am/using
>
Nope, I think you're confused.
If I want to tag some really deep directory in my working copy, I
don't need to cd in there at all. It's optional. I can just specify
the deep wc path as the first argument to 'svn cp', or I can cd in and
specify '.' as the first argument. There's no difference.
Secondly, I can "copy" my wc directory to any location I want on the
server. The 2nd argument can be any old URL I want, shallow or deep.
It just depends on how I've laid out the server. Remember, a tag is
just an ordinary directory in the repository filesystem -- it could go
anywhere. (If this is news to you, read the design spec, or the end
of the "SVN for CVS users" doc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: M7: Branches and Tags
Posted by Bruce Atherton <br...@callenish.com>.
At 04:31 PM 11/13/2001 -0600, Ben Collins-Sussman wrote:
> cd top/of/my/wc
> svn cp . http://foo.com/repos/project1/tags/milestone-6
If I understand you correctly, though, if you want to move a tag deep in
your wc, you have to do something like this:
cd top/of/my/wc/some/really/deep/directory/path/I/am/using
svn cp .
http://foo.com/repos/project1/tags/milestone-6/some/really/deep/directory/path/I/am/using
This doesn't compare well with CVS:
cd top/of/my/wc/some/really/deep/directory/path/I/am/using
cvs tag -F milestone-6
Speaking of the "-F', is the cp command going to have a similar (or
opposite) flag?
What might work would be if there were some way to set a change in some
arbitrary section of the URL. I have no idea what a sensible user interface
for this would look like, but just to give you an idea:
cd top/of/my/wc/some/really/deep/directory/path/I/am/using
svn cp --repos-replace trunk:tags/milestone-6 .
Still a heck of a lot of work just to tag a file, but better than above. Of
course, if I have all this wrong and tagging a file deep in a wc is easy,
just ignore the whole thing.
>Second, we have a new command: 'svn switch URL [-r rev]'
I like this very much, and not just for the use cases you give.
In the CVS world, it has not been uncommon to want to change all of the
CVS/Root files within a wc. This could be due to a server change, moving
the position of the repository in the file system, or even (given how the
pserver CVSROOT is specified) the name of the user to authenticate against.
It is common enough to want to change this that WinCVS ships with a TCL
macro to change the CVS/Root files within a wc.
Even without the authentication issue, this problem will continue to bite
people. The switch command could presumably be used to deal with a
repository move as well as the other use cases you mentioned.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: M7: Branches and Tags
Posted by Sander Striker <st...@apache.org>.
> [Note: we're using the phrase "tag" to mean "branch or tag"; they're
> the same thing, and for now we're assuming that per-installation
> administrative policy and/or ACLs will bother to differentiate. The
> svn filesystem certainly doesn't.]
Just a sidenote, it might be a good idea to have a tag command later
on, when ACLs are implemented. This would then do exactly what cp
does now, with the addition of setting all the ACLs to read-only.
But, don't bother with thinking about that now, because we are a long
way from ACLs :)
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org