No, what I'm mainly doing is a convenience feature, aimed at making
the command set more approachable.
It's something like this:
svn commit blah-blah --tag URL
...is functionally the same as:
svn copy blah-blah URL
svn commit blah-blah
THe only difference being that this occurs in a single commit and
hence the checkin *and* the tag is done at the same time. Makes for a
much easier audit trail.
Of course, you _can_ do this:
svn copy blah-blah local-path-to-tag
svn commit blah-blah local-path-to-tag
But I think my suggestion buys a couple of things:
-- It's a single command, so easier for users to remember/run, a
fewer errors that need tricky cleanup
-- It starts to make tags a little more first-class: the --tag switch
can be "smart" about the URL, since the command *knows* its a tag,
not any old branch.
-- Working copies don't accumulate local-path-to-tag junk (yes, easy
to cleanup, but again this is a workflow streamlining issue).
--Tim
But in my experience
On Nov 21, 2006, at 12:34 AM, Tony Harverson wrote:
> Hi There Tim,
>
>> -----Original Message-----
>> From: Tim Hill [mailto:drtimhill@comcast.net]
>> [2] The ability to create a tag at commit time in one single
>> atomic operation, via some sort of --tag switch to svn
>> commit. This would certainly take care of issue (1) for me
>> and would, I suspect, make
>> (2b) go away for a lot of people. And, yes, I'm aware that
>> this is also a tricky feature to get "right".
>
> This feature, as it has been discussed in this thread in the past,
> was to allow the user to commit their workspace to a Label/Tag without
> worrying what's in HEAD, right? So you commit a copy of foo.c with
> changes
> that you've made to make the build work, and it commits that file
> (along
> with all the others in your workspace) to the repository, and
> labels them
> with the label?
>
> So.. Where does the above commit (commit my workspace to tag
> PRODUCTION_1_1) go,
> if there are existing changes in the HEAD revision of the files you're
> committing? Does it Merge them in, commit over them (and then
> revert them
> in the next rev?), or fail completely?
>
> Or does Subversion have to support the introduction of non-
> sequential changes?
> (r 10 -> r 12) with r11 on the side(and not affecting/affecting
> HEAD?) because
> that's a commit from a user's tagged workspace?
>
> - Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 17:33:28 2006