You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tim Liu <ti...@gmail.com> on 2006/11/10 00:05:37 UTC
Is label support in future release?
Folks,
I have seen dev forum talk about label support:
http://subversion.tigris.org/servlets/BrowseList?windowSize=50&by=thread&from=180403&to=180403&count=23&first=1&list=dev&selectedPage=1
I don't see it in roadmap:
http://subversion.tigris.org/roadmap.html#release-planning
Is it still in plan for future release?
thx
Tim
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
Agreed ... but you won't get the svn devs to agree.
--Tim
On Nov 14, 2006, at 3:30 AM, Phyrefly wrote:
> I agree, tags provide all the needed features, but they're far too
> complex (and expensive in terms of ease-of-use if nothing else) to be
> used as labels. I would like to be able to label my repo at the point
> I do a release, but I have no intention of treating it as a branch,
> just a convenient way of getting that code back. Currently I'm using
> the datestamp on my release log as a means of doing an export of a
> particular point in the repo's history.
>
> It's the one feature missing from SVN as far as I'm concerned.
>
> Richard.
>
> On 14/11/06, Tim Hill <dr...@comcast.net> wrote:
>> If by "label" you mean some sort of name tag for a rev#, then
>> you're out of
>> luck -- it's been debated here several times and met with strong
>> resistance
>> by the svn developers, who feel that tags provide all the needed
>> features.
>>
>> --Tim
>>
>>
>> On Nov 9, 2006, at 4:05 PM, Tim Liu wrote:
>> Folks,
>>
>> I have seen dev forum talk about label support:
>>
>> http://subversion.tigris.org/servlets/BrowseList?
>> windowSize=50&by=thread&from=180403&to=180403&count=23&first=1&list=d
>> ev&selectedPage=1
>>
>> I don't see it in roadmap:
>> http://subversion.tigris.org/roadmap.html#release-planning
>>
>> Is it still in plan for future release?
>>
>> thx
>>
>> Tim
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Talden <ta...@gmail.com>.
I don't see how they increase working copies. If the repository is
projectX/
trunk/
branches/
b1/
b2/
tags/
t1/
t2/
And the project contains say 20,000 files and 2,000 folders you don't
checkout /projectX and get 100,000 files and 10,008 folders. Instead
you checkout /projectX/trunk and get 20,000 files and 2,001 folders.
You only get more files/folders in your working copy if you have
multiple working copies. Of course this is a completely separate
issue from the extra files associated with pristine copies.
... Hypothetical location where I'm keeping my working copies
> cd /work
...Checking out the trunk to a default working copy.
> svn co svn://server/repos/projectX/trunk default
...Entering the working copy and switching it to a different branch.
> cd /work/default
> svn switch svn://server/repos/projectX/branches/b1
...Where is my working copy right now?...
> cd /work/default
> svn info
Hopefully that's all right... I'm still rather green.
Surely creating the tags and branches are immediately commitable and
so are repository commands rather than working copies in most
situations.
--
Talden
On 15/11/06, Joseph Mocker <mo...@fakebelieve.org> wrote:
> This might be somewhat off topic, but the problem I see with tags and
> branches as they are supported in Subversion is that they lead to such
> an exponential growth in working copies such that there is no way one
> could checkout an entire project, even moderately sized (2000 files, 100
> tags) including trunk, tags & branches without taxing resources in some
> way (disk, cpu, developer time)
>
> The downside is that developers need to learn tricks to deal with this.
> For example, developers should only checkout the trunk, but that isn't a
> one step operation if you want to preserve directory structure of say
> project/trunk. First I must "svn checkout -N project", then "cd project;
> svn update trunk".
>
> That way when I create a tag, I can just "cd project; mkdir tags; svn
> add tags; svn copy trunk tags/tagname". Straight forward, just not a
> single operation, and the more operations, the more possibility to
> foobar something.
>
> --joe
>
>
> Talden wrote:
> > I don't know that the effort of creating a label would be any less...
> > but some common manipulations might be.
> >
> > 1) moving a label means removing the old and recreating it - no need
> > for history since a label is a point in history. Moving a tag is a
> > delete and a recopy which does turn up in history.
> >
> > 2) listing logs between two labels (since they're revision aliases) is
> > trivial. Doing the same from tags is non-trivial requiring two logs
> > with stop on copy to get the revisions in question.
> >
> > Perhaps if we were to list all of the expected uses of labels, then
> > for each use discuss what the existing facilities provide for in the
> > way of solutions. We then need to postulate as to how labels would
> > either better facilitate these processes and perhaps what
> > functionality labels might give beyond what is practical using
> > existing facilities.
> >
> > I expect such a formal approach will be the only means by which you
> > convince existing developers (or draw in new developers) to add this
> > feature.
> >
> > I'll start with the obvious simple case.
> >
> > 1. Labels provide a contextual and memorable alias for a revision number.
> >
> > A tag can do this as well. You create the tag and then when you need
> > the revision number it refers to you must execute a log 'stop on copy'
> > command on the tag URL.
> >
> > A label on the other-hand is an explicit alias for a revision number
> > and could be used directly.
> >
> > svn label -rN pre_import_checkpoint
> > ...
> > svn log -rpre_import_checkpoint:HEAD ...
> >
> > --
> > Talden
> >
> > On 15/11/06, Nikki Locke <in...@trumphurst.com> wrote:
> >> Phyrefly wrote:
> >> > I agree, tags provide all the needed features, but they're far too
> >> > complex (and expensive in terms of ease-of-use if nothing else) to be
> >> > used as labels. I would like to be able to label my repo at the point
> >> > I do a release, but I have no intention of treating it as a branch,
> >> > just a convenient way of getting that code back. Currently I'm using
> >> > the datestamp on my release log as a means of doing an export of a
> >> > particular point in the repo's history.
> >>
> >> What's the ease-of-use difference between creating a tag, and
> >> creating a "label"?
> >>
> >> What command would you run to create a label?
> >> How does that compare with the command you would run to create a tag?
> >>
> >> --
> >> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
> >> http://www.trumphurst.com/
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: users-help@subversion.tigris.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by John Allen <jo...@dublinux.net>.
Joseph Mocker wrote:
> This might be somewhat off topic, but the problem I see with tags and
> branches as they are supported in Subversion is that they lead to such
> an exponential growth in working copies such that there is no way one
> could checkout an entire project, even moderately sized (2000 files,
> 100 tags) including trunk, tags & branches without taxing resources in
> some way (disk, cpu, developer time)
>
> The downside is that developers need to learn tricks to deal with
> this. For example, developers should only checkout the trunk, but
> that isn't a one step operation if you want to preserve directory
> structure of say project/trunk. First I must "svn checkout -N
> project", then "cd project; svn update trunk".
>
Don't preserve directory structure, just checkout trunk to project
eg.
svn co svn+ssh://svn.example.com/var/svn/project/trunk project
cd project
> That way when I create a tag, I can just "cd project; mkdir tags; svn
> add tags; svn copy trunk tags/tagname". Straight forward, just not a
> single operation, and the more operations, the more possibility to
> foobar something.
>
Only do svn copy on repository url's
eg.
svn copy svn+ssh://svn.example.com/var/svn/project/trunk
svn+ssh://svn.example.com/var/svn/project/tags/test
svn co svn+ssh://svn.example.com/var/svn/project/trunk project
then locally
do
svn switch svn+ssh://svn.example.com/var/svn/project/tags/test
> --joe
>
>
> Talden wrote:
>> I don't know that the effort of creating a label would be any less...
>> but some common manipulations might be.
>>
>> 1) moving a label means removing the old and recreating it - no need
>> for history since a label is a point in history. Moving a tag is a
>> delete and a recopy which does turn up in history.
>>
>> 2) listing logs between two labels (since they're revision aliases) is
>> trivial. Doing the same from tags is non-trivial requiring two logs
>> with stop on copy to get the revisions in question.
>>
>> Perhaps if we were to list all of the expected uses of labels, then
>> for each use discuss what the existing facilities provide for in the
>> way of solutions. We then need to postulate as to how labels would
>> either better facilitate these processes and perhaps what
>> functionality labels might give beyond what is practical using
>> existing facilities.
>>
>> I expect such a formal approach will be the only means by which you
>> convince existing developers (or draw in new developers) to add this
>> feature.
>>
>> I'll start with the obvious simple case.
>>
>> 1. Labels provide a contextual and memorable alias for a revision
>> number.
>>
>> A tag can do this as well. You create the tag and then when you need
>> the revision number it refers to you must execute a log 'stop on copy'
>> command on the tag URL.
>>
>> A label on the other-hand is an explicit alias for a revision number
>> and could be used directly.
>>
>> svn label -rN pre_import_checkpoint
>> ...
>> svn log -rpre_import_checkpoint:HEAD ...
>>
>> --
>> Talden
>>
>> On 15/11/06, Nikki Locke <in...@trumphurst.com> wrote:
>>> Phyrefly wrote:
>>> > I agree, tags provide all the needed features, but they're far too
>>> > complex (and expensive in terms of ease-of-use if nothing else) to be
>>> > used as labels. I would like to be able to label my repo at the
>>> point
>>> > I do a release, but I have no intention of treating it as a branch,
>>> > just a convenient way of getting that code back. Currently I'm using
>>> > the datestamp on my release log as a means of doing an export of a
>>> > particular point in the repo's history.
>>>
>>> What's the ease-of-use difference between creating a tag, and
>>> creating a "label"?
>>>
>>> What command would you run to create a label?
>>> How does that compare with the command you would run to create a tag?
>>>
>>> --
>>> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
>>> http://www.trumphurst.com/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Joseph Mocker <mo...@fakebelieve.org>.
Andy Peters wrote:
> On Nov 14, 2006, at 2:47 PM, Joseph Mocker wrote:
> I guess the question is why would you want or need to check out the
> entire project? Check out the trunk if you're working on the trunk.
> Check out a branch if you're working on a branch.
I should have clarified more that for developers who are used to working
in CVS where you can checkout an entire project w/o such a penalty, its
a change in the way they work.
>
>> That way when I create a tag, I can just "cd project; mkdir tags;
>> svn add tags; svn copy trunk tags/tagname". Straight forward, just
>> not a single operation, and the more operations, the more
>> possibility to foobar something.
>
>
> That's WAAAY too complicated! I do something similar and easier,
> without checking out the entire project (all branches, all tags, plus
> the trunk). I just create the tag directly on the server.
>
> $ cd workingcopyoftrunk
> $ svn copy . svn://server/project1/tags/newtag
>
> Simple, eh?
>
yes, I should have been more verbose in my previous mail in which I was
aware of issuing a copy command against two URLs. It its nice and quick.
However, Subversion didn't like me trying to copy to
svn://server/project1/tags/newtag if /projec1/tags didn't exist first.
--joe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Andy Peters <de...@latke.net>.
On Nov 14, 2006, at 2:47 PM, Joseph Mocker wrote:
> This might be somewhat off topic, but the problem I see with tags
> and branches as they are supported in Subversion is that they lead
> to such an exponential growth in working copies such that there is
> no way one could checkout an entire project, even moderately sized
> (2000 files, 100 tags) including trunk, tags & branches without
> taxing resources in some way (disk, cpu, developer time)
>
> The downside is that developers need to learn tricks to deal with
> this. For example, developers should only checkout the trunk, but
> that isn't a one step operation if you want to preserve directory
> structure of say project/trunk. First I must "svn checkout -N
> project", then "cd project; svn update trunk".
I guess the question is why would you want or need to check out the
entire project? Check out the trunk if you're working on the trunk.
Check out a branch if you're working on a branch.
> That way when I create a tag, I can just "cd project; mkdir tags;
> svn add tags; svn copy trunk tags/tagname". Straight forward, just
> not a single operation, and the more operations, the more
> possibility to foobar something.
That's WAAAY too complicated! I do something similar and easier,
without checking out the entire project (all branches, all tags, plus
the trunk). I just create the tag directly on the server.
$ cd workingcopyoftrunk
$ svn copy . svn://server/project1/tags/newtag
Simple, eh?
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Joseph Mocker <mo...@fakebelieve.org>.
This might be somewhat off topic, but the problem I see with tags and
branches as they are supported in Subversion is that they lead to such
an exponential growth in working copies such that there is no way one
could checkout an entire project, even moderately sized (2000 files, 100
tags) including trunk, tags & branches without taxing resources in some
way (disk, cpu, developer time)
The downside is that developers need to learn tricks to deal with this.
For example, developers should only checkout the trunk, but that isn't a
one step operation if you want to preserve directory structure of say
project/trunk. First I must "svn checkout -N project", then "cd project;
svn update trunk".
That way when I create a tag, I can just "cd project; mkdir tags; svn
add tags; svn copy trunk tags/tagname". Straight forward, just not a
single operation, and the more operations, the more possibility to
foobar something.
--joe
Talden wrote:
> I don't know that the effort of creating a label would be any less...
> but some common manipulations might be.
>
> 1) moving a label means removing the old and recreating it - no need
> for history since a label is a point in history. Moving a tag is a
> delete and a recopy which does turn up in history.
>
> 2) listing logs between two labels (since they're revision aliases) is
> trivial. Doing the same from tags is non-trivial requiring two logs
> with stop on copy to get the revisions in question.
>
> Perhaps if we were to list all of the expected uses of labels, then
> for each use discuss what the existing facilities provide for in the
> way of solutions. We then need to postulate as to how labels would
> either better facilitate these processes and perhaps what
> functionality labels might give beyond what is practical using
> existing facilities.
>
> I expect such a formal approach will be the only means by which you
> convince existing developers (or draw in new developers) to add this
> feature.
>
> I'll start with the obvious simple case.
>
> 1. Labels provide a contextual and memorable alias for a revision number.
>
> A tag can do this as well. You create the tag and then when you need
> the revision number it refers to you must execute a log 'stop on copy'
> command on the tag URL.
>
> A label on the other-hand is an explicit alias for a revision number
> and could be used directly.
>
> svn label -rN pre_import_checkpoint
> ...
> svn log -rpre_import_checkpoint:HEAD ...
>
> --
> Talden
>
> On 15/11/06, Nikki Locke <in...@trumphurst.com> wrote:
>> Phyrefly wrote:
>> > I agree, tags provide all the needed features, but they're far too
>> > complex (and expensive in terms of ease-of-use if nothing else) to be
>> > used as labels. I would like to be able to label my repo at the point
>> > I do a release, but I have no intention of treating it as a branch,
>> > just a convenient way of getting that code back. Currently I'm using
>> > the datestamp on my release log as a means of doing an export of a
>> > particular point in the repo's history.
>>
>> What's the ease-of-use difference between creating a tag, and
>> creating a "label"?
>>
>> What command would you run to create a label?
>> How does that compare with the command you would run to create a tag?
>>
>> --
>> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
>> http://www.trumphurst.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Talden <ta...@gmail.com>.
I don't know that the effort of creating a label would be any less...
but some common manipulations might be.
1) moving a label means removing the old and recreating it - no need
for history since a label is a point in history. Moving a tag is a
delete and a recopy which does turn up in history.
2) listing logs between two labels (since they're revision aliases) is
trivial. Doing the same from tags is non-trivial requiring two logs
with stop on copy to get the revisions in question.
Perhaps if we were to list all of the expected uses of labels, then
for each use discuss what the existing facilities provide for in the
way of solutions. We then need to postulate as to how labels would
either better facilitate these processes and perhaps what
functionality labels might give beyond what is practical using
existing facilities.
I expect such a formal approach will be the only means by which you
convince existing developers (or draw in new developers) to add this
feature.
I'll start with the obvious simple case.
1. Labels provide a contextual and memorable alias for a revision number.
A tag can do this as well. You create the tag and then when you need
the revision number it refers to you must execute a log 'stop on copy'
command on the tag URL.
A label on the other-hand is an explicit alias for a revision number
and could be used directly.
svn label -rN pre_import_checkpoint
...
svn log -rpre_import_checkpoint:HEAD ...
--
Talden
On 15/11/06, Nikki Locke <in...@trumphurst.com> wrote:
> Phyrefly wrote:
> > I agree, tags provide all the needed features, but they're far too
> > complex (and expensive in terms of ease-of-use if nothing else) to be
> > used as labels. I would like to be able to label my repo at the point
> > I do a release, but I have no intention of treating it as a branch,
> > just a convenient way of getting that code back. Currently I'm using
> > the datestamp on my release log as a means of doing an export of a
> > particular point in the repo's history.
>
> What's the ease-of-use difference between creating a tag, and creating a "label"?
>
> What command would you run to create a label?
> How does that compare with the command you would run to create a tag?
>
> --
> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
> http://www.trumphurst.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Posted by us...@subversion.tigris.org.
98@eskimo.com>
From: Nikki Locke <in...@trumphurst.com>
Reply-To: users@subversion.tigris.org
Subject: Re: Is label support in future release?
Thomas Wicklund wrote:
> You need to use something like:
>
> svn diff --old foo.c --new <some-url>
Why is that? Why not assume that the first argument of a pair is the old
version, and the second the new version (or the other way round, if it matches
user expectations better). Why insist on this extra syntax?
And, if this extra syntax is necessary, why is the error message so unhelpful -
if it said "try svn diff --old <url> --new <url>" you might have a clue what to
do next.
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
> You need to use something like:
>
> svn diff --old foo.c --new <some-url>
I can confirm this. (Just for the record.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Thomas Wicklund <wi...@eskimo.com>.
Nikki Locke writes:
> Tim Hill wrote:
> > I agree .. *getting* the rev# was not the issue, though. It was what
> > I do with it when I've got it:
> >
> > Workflow 1 (today):
> > (1) enter: svn info <some-url>
> > (2) manually scan the output for the rev#, call it X
> > (3) enter: svn diff foo.c -r X:HEAD
> >
> > Workflow 2 (with proposed feature):
> > (1) enter: svn diff foo.c -r <some-url>:HEAD
>
> I had assumed svn would allow you to do
>
> svn diff foo.c <some-url>
>
> but it seems to give the error message:
> svn: Target lists to diff may not contain both working copy paths and URLs
>
> Why is this disallowed? It is such an obvious requirement, and would solve
> most of the use cases of people who want labels.
You need to use something like:
svn diff --old foo.c --new <some-url>
Working copy paths are only allowed in the --old or --new arguments.
I've been tripped up by this a few times, I now always use --new and
--old for differences.
I have seen strange things even with these parameters where the
working copy is used when I don't think it should be (or a committed
copy when I think it should be the working copy), however I haven't
been able to track down whether there's a problem in SVN or if I'm
confused.
Thomas Wicklund
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Tim Hill wrote:
> I agree .. *getting* the rev# was not the issue, though. It was what
> I do with it when I've got it:
>
> Workflow 1 (today):
> (1) enter: svn info <some-url>
> (2) manually scan the output for the rev#, call it X
> (3) enter: svn diff foo.c -r X:HEAD
>
> Workflow 2 (with proposed feature):
> (1) enter: svn diff foo.c -r <some-url>:HEAD
I had assumed svn would allow you to do
svn diff foo.c <some-url>
but it seems to give the error message:
svn: Target lists to diff may not contain both working copy paths and URLs
Why is this disallowed? It is such an obvious requirement, and would solve
most of the use cases of people who want labels.
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Mon, 20 Nov 2006, Les Mikesell wrote:
> That's not an interesting scenario because you don't
> make changes. The one we are discussing is:
>
> You: svn checkout url://repository/project/trunk
> You: change file(s)
> Other people: commit more stuff - that you don't want now -
> You: commit changes
> You: decide what you have is good for testing
> You: svn copy -m 'create tag foo for testing' \
> . url://repository/project/tags/foo
>
> At this point you have what you want in the copy, and
> the trunk also includes your changes, but no revision on
> the trunk is an exact match for the tag.
Now I understand the disconnect. I wasn't discussing that scenario,
thought I did acknowledge that it was possible.
> > [Remainder snipped. This thread is much too long.]
>
> Sorry, but it is long because you suggested that the
> above scenario is not the best practice and still have
> not explained either the problem it poses or a better
> approach.
It doesn't pose any problem, except violation of the (possibly weak)
assumption that a tag marks a point in time. If I had to do that,
I'd be sure to explain the reason in the log message when I create the
tag.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-21 at 15:00 +0100, Gerco Ballintijn wrote:
> >
> > You: svn checkout url://repository/project/trunk
> > You: change file(s)
> > Other people: commit more stuff - that you don't want now -
> > You: commit changes
> > You: decide what you have is good for testing
> > You: svn copy -m 'create tag foo for testing' \
> > . url://repository/project/tags/foo
> >
> > At this point you have what you want in the copy, and
> > the trunk also includes your changes, but no revision on
> > the trunk is an exact match for the tag.
> >
>
> Your scenario is faulty.
>
> You cannot directly commit since the the HEAD revision has
> moved on due to the other people's commits. You first have
> to update, and will thus include these other changes.
No, please see the 'Mixed Revision Working Copies" section of
the svn book, expecially 'Updates and Commits are Separate'
followed by 'Mixed revisions are normal'. There are some
limits but it is a common occurrence when different people
work on different file in the same project concurrently and
it leads to many working copy states that you'd like to be
able to reproduce for testing or even release that don't and
can't exist as repository revisions because things you don't
want to include were committed first. And then the svn client
operations that expect to operate on repository revisions aren't
a real good fit.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Gerco Ballintijn <ge...@ballintijn.com>.
Les Mikesell wrote:
> On Mon, 2006-11-20 at 01:38, Alan Barrett wrote:
>
>>> The part I'm having trouble with is how to permit ongoing concurrent
>>> development in the repository beyond the workspace copy containing the
>>> state you want to tag.
>> You don't need to do anything special to permit that; it just works.
>>
>> You: svn checkout -r 100 url://repository/project/trunk
>> Other people: commit stuff
>> You: test
>> Other people: commit more stuff
>> You: decide that test was successful
>> You: svn copy -m 'create tag foo from trunk revision 100' \
>> -r 100 url://repository/project/trunk \
>> url://repository/project/tags/foo
>
> That's not an interesting scenario because you don't
> make changes. The one we are discussing is:
>
> You: svn checkout url://repository/project/trunk
> You: change file(s)
> Other people: commit more stuff - that you don't want now -
> You: commit changes
> You: decide what you have is good for testing
> You: svn copy -m 'create tag foo for testing' \
> . url://repository/project/tags/foo
>
> At this point you have what you want in the copy, and
> the trunk also includes your changes, but no revision on
> the trunk is an exact match for the tag.
>
Your scenario is faulty.
You cannot directly commit since the the HEAD revision has
moved on due to the other people's commits. You first have
to update, and will thus include these other changes.
Greetings,
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Mon, 2006-11-20 at 01:38, Alan Barrett wrote:
> > The part I'm having trouble with is how to permit ongoing concurrent
> > development in the repository beyond the workspace copy containing the
> > state you want to tag.
>
> You don't need to do anything special to permit that; it just works.
>
> You: svn checkout -r 100 url://repository/project/trunk
> Other people: commit stuff
> You: test
> Other people: commit more stuff
> You: decide that test was successful
> You: svn copy -m 'create tag foo from trunk revision 100' \
> -r 100 url://repository/project/trunk \
> url://repository/project/tags/foo
That's not an interesting scenario because you don't
make changes. The one we are discussing is:
You: svn checkout url://repository/project/trunk
You: change file(s)
Other people: commit more stuff - that you don't want now -
You: commit changes
You: decide what you have is good for testing
You: svn copy -m 'create tag foo for testing' \
. url://repository/project/tags/foo
At this point you have what you want in the copy, and
the trunk also includes your changes, but no revision on
the trunk is an exact match for the tag.
> [Remainder snipped. This thread is much too long.]
Sorry, but it is long because you suggested that the
above scenario is not the best practice and still have
not explained either the problem it poses or a better
approach. I do see the possibility of an error by
forgetting to commit to the trunk, but I can't see
how that goes away even if you do the extra steps to
make your own branch.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 20, 2006, at 13:00, Andy Peters wrote:
> On Nov 20, 2006, at 11:17 AM, Thomas Wicklund wrote:
>
>> This shows the problem with the current method. Why did you checkout
>> revision 100? Was it the head revision at the time? The main
>> repository I use is at around revision 20,000. A legacy
>> repository is
>> also at about the same revision number. The revision number probably
>> increments by 10-20 each day.
>
> Thanks for pointing this out! I agree; why are people concerned
> with checking out a specific (and probably outdated) revision from
> which they start to work? Sounds like it's better to create a
> branch (possibly from a tag) and start there, then merge back to
> the trunk.
I assumed one of these scenarios:
foo) I finish working on a feature, and end up committing revision
100. I send an email to the testing department asking them to test
this new feature and tag it when they're done. They may not get this
email until tomorrow or whenever, but I want to continue coding on
other features, but I don't want the testing department to get any
half-finished code while I'm working on it and committing things.
Which is why it's important for me to tell them to check out revision
100 specifically. But it might be better in this scenario for me to
create the tag, and tell the testing team the name of the tag. I'm
not sure what exactly the workflow would be, but I'm sure there are
many options. For example, I could tag it to a directory of things
that are ready to be tested; once tested successfully, the testing
team could tag it to a directory of things that have passed testing.
bar) Software version 1.0 is released. Work continues on trunk
towards version 2.0. After weeks or months of work have gone by, a
bug is found in version 1.0 and we want to quickly release a version
1.0.1. But we can't possibly do so from the current state of trunk
because it includes many new features that should only appear in 2.0.
So we go back to the revision of trunk from which 1.0 was released;
we discover in the log that this was revision 100. We can check this
out, fix the bug, and release 1.0.1. Of course, we should actually
just copy revision 100 of trunk to a 1.0 branch, check out the HEAD
of the 1.0 branch, fix the bug there, and commit it. And then tag
1.0.1 from the 1.0 branch. Of course, if we're tagging, then there
would already have been a 1.0 tag, which we could have copied to make
a 1.0 branch without needing to know any revision number. So this
turns out not to be a reason for checking out an old revision either.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Gerco Ballintijn <ge...@ballintijn.com>.
Thomas Wicklund wrote:
> Andy Peters writes:
>> On Nov 20, 2006, at 11:17 AM, Thomas Wicklund wrote:
>>> I'm not sure this is the exact case the original poster wanted, but I
>>> would argue that the point of tagging and branching is that you always
>>> work with tag / branch names, never with revision numbers.
>>> Unfortunately the SVN book seems to assume that users routinely track
>>> revision numbers when checking out and committing. Repository
>>> revision numbers change too often for this to be practical.
>>
>> I agree. I think the emphasis on revision numbers is in the book
>> because revision numbers are used when merging. Other than that, I
>> don't pay any attention to revision numbers at all.
>
> You shouldn't need revision numbers when merging either. Remembering
> which revision a branch is based on is the biggest complaint I've
> heard from people moving to Subversion. Unfortunately, You really
> need to enforce additional structure on top of Subversion or some good
> discipline to manage branches so that revision numbers aren't needed.
>
Isn't this structure provided by the svnmerge script?
Greetings,
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Thomas Wicklund <wi...@eskimo.com>.
Andy Peters writes:
> On Nov 20, 2006, at 11:17 AM, Thomas Wicklund wrote:
> > I'm not sure this is the exact case the original poster wanted, but I
> > would argue that the point of tagging and branching is that you always
> > work with tag / branch names, never with revision numbers.
> > Unfortunately the SVN book seems to assume that users routinely track
> > revision numbers when checking out and committing. Repository
> > revision numbers change too often for this to be practical.
>
> I agree. I think the emphasis on revision numbers is in the book
> because revision numbers are used when merging. Other than that, I
> don't pay any attention to revision numbers at all.
You shouldn't need revision numbers when merging either. Remembering
which revision a branch is based on is the biggest complaint I've
heard from people moving to Subversion. Unfortunately, You really
need to enforce additional structure on top of Subversion or some good
discipline to manage branches so that revision numbers aren't needed.
Thomas Wicklund
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Andy Peters <de...@latke.net>.
On Nov 20, 2006, at 11:17 AM, Thomas Wicklund wrote:
> This shows the problem with the current method. Why did you checkout
> revision 100? Was it the head revision at the time? The main
> repository I use is at around revision 20,000. A legacy repository is
> also at about the same revision number. The revision number probably
> increments by 10-20 each day.
Thanks for pointing this out! I agree; why are people concerned with
checking out a specific (and probably outdated) revision from which
they start to work? Sounds like it's better to create a branch
(possibly from a tag) and start there, then merge back to the trunk.
> I'm not sure this is the exact case the original poster wanted, but I
> would argue that the point of tagging and branching is that you always
> work with tag / branch names, never with revision numbers.
> Unfortunately the SVN book seems to assume that users routinely track
> revision numbers when checking out and committing. Repository
> revision numbers change too often for this to be practical.
I agree. I think the emphasis on revision numbers is in the book
because revision numbers are used when merging. Other than that, I
don't pay any attention to revision numbers at all.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Thomas Wicklund <wi...@eskimo.com>.
Alan Barrett writes:
> On Sun, 19 Nov 2006, Les Mikesell wrote:
> > The part I'm having trouble with is how to permit ongoing concurrent
> > development in the repository beyond the workspace copy containing > > state you want to tag.
>
> You don't need to do anything special to permit that; it just works.
>
> You: svn checkout -r 100 url://repository/project/trunk
> Other people: commit stuff
> You: test
> Other people: commit more stuff
> You: decide that test was successful
> You: svn copy -m 'create tag foo from trunk revision 100' \
> -r 100 url://repository/project/trunk \
> url://repository/project/tags/foo
This shows the problem with the current method. Why did you checkout
revision 100? Was it the head revision at the time? The main
repository I use is at around revision 20,000. A legacy repository is
also at about the same revision number. The revision number probably
increments by 10-20 each day.
I'd suggest instead:
You: svn copy -m 'create candidate tag foo on mm/dd/yyyy from trunk' \
url://repository/project/trunk \
url://repository/project/tags/foo.test
You: svn checkout url://repository/project/tags/foo.test
Other people: commit stuff
You: test
Other people: commit more stuff
You: decide that test was successful
You: svn move -m 'create tag foo of mm/dd/yyyy' \
url://repository/project/tags/foo.test \
url://repository/project/tags/foo
I'm not sure this is the exact case the original poster wanted, but I
would argue that the point of tagging and branching is that you always
work with tag / branch names, never with revision numbers.
Unfortunately the SVN book seems to assume that users routinely track
revision numbers when checking out and committing. Repository
revision numbers change too often for this to be practical.
Thomas Wicklund
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Sun, 19 Nov 2006, Les Mikesell wrote:
> The part I'm having trouble with is how to permit ongoing concurrent
> development in the repository beyond the workspace copy containing the
> state you want to tag.
You don't need to do anything special to permit that; it just works.
You: svn checkout -r 100 url://repository/project/trunk
Other people: commit stuff
You: test
Other people: commit more stuff
You: decide that test was successful
You: svn copy -m 'create tag foo from trunk revision 100' \
-r 100 url://repository/project/trunk \
url://repository/project/tags/foo
[Remainder snipped. This thread is much too long.]
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Sun, 2006-11-19 at 01:06, Alan Barrett wrote:
> > Is there a reason not to?
>
> Tagging is extra effort, extra entries in the logs, extra directories
> in the view presented by a repository browser. Why use tags (which are
> really copies in subversion) if you can get away with revision numbers?
Aren't revision numbers also copies in subversion? The part I'm
having trouble with is how to permit ongoing concurrent development
in the repository beyond the workspace copy containing the
state you want to tag. Maybe I've taken the CVS arguments for
the usefulness of this feature too seriously. It has been rare
in practice except for web content where a marketing group
changes portions in a way that does not need much coordination
with the functional parts, but still I don't ever want to
tell someone they can't commit new work or that they have
to make a branch because the system needs it for concurrent
work.
> > Sorry to drag it out then, but coming from CVS where tagging is the
> > only way to represent a known state [...]
>
> With CVS, I usually used "-r ${branch} -D ${date_time}" to represent
> a candidate for testing. I am aware that that that checkouts with
> the -D flag don't always do the right thing in CVS, especially in
> conjunction with vendor branches, but they always worked well enough for
> me.
This has the same issue in that the repository branch
may have had additional commits beyond the state of the
workspace that you want to duplicate for the test. That
is, you want to pick up the commits from that workspace
but no others beyond it's last update. Maybe my perspective
is warped from dealing with developers in a different country
adding "tomorrow's" work overlapping with the time you might
be running tests against today's changes by a different group.
If you are a single developer or a small local group you might
never have a concurrency problem but it seems like something
a version control system should handle.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 18 Nov 2006, Les Mikesell wrote:
> > > What's the advantage of the tester pulling a branch revision
> > > number instead of a tag?
> >
> > As I said, your workflow is clearly different from mine. I'd expect
> > almost every revision in the stable branch to be a candidate for
> > testing, so there's no reason to tag them before testing.
>
> Is there a reason not to?
Tagging is extra effort, extra entries in the logs, extra directories
in the view presented by a repository browser. Why use tags (which are
really copies in subversion) if you can get away with revision numbers?
> > I am sorry that what was intended as a simple "if you are not
> > careful your tag will end up with mixed revisions and that can be
> > confusing" has turned into such a long thread.
>
> Sorry to drag it out then, but coming from CVS where tagging is the
> only way to represent a known state [...]
With CVS, I usually used "-r ${branch} -D ${date_time}" to represent
a candidate for testing. I am aware that that that checkouts with
the -D flag don't always do the right thing in CVS, especially in
conjunction with vendor branches, but they always worked well enough for
me. Revision numbers in subversion are a more reliable way of getting
the same effect.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Sat, 2006-11-18 at 14:58, Alan Barrett wrote:
> > What's the advantage of the tester pulling a branch revision
> > number instead of a tag?
>
> As I said, your workflow is clearly different from mine. I'd expect
> almost every revision in the stable branch to be a candidate for
> testing, so there's no reason to tag them before testing.
Is there a reason not to?
> I am sorry that what was intended as a simple "if you are not careful
> your tag will end up with mixed revisions and that can be confusing" has
> turned into such a long thread.
Sorry to drag it out then, but coming from CVS where tagging
is the only way to represent a known state and you expect the
repository head to always be changing it just seems odd to
even think about what the rest of the repository has done
when you tag what you currently have. Am I missing a big
advantage of subversion by mostly ignoring the repository
revisions since CVS didn't have them?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 18 Nov 2006, Les Mikesell wrote:
> What's the advantage of the tester pulling a branch revision
> number instead of a tag?
As I said, your workflow is clearly different from mine. I'd expect
almost every revision in the stable branch to be a candidate for
testing, so there's no reason to tag them before testing.
I am sorry that what was intended as a simple "if you are not careful
your tag will end up with mixed revisions and that can be confusing" has
turned into such a long thread.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Sat, 2006-11-18 at 13:31, Alan Barrett wrote:
> > > Me too. Checking out a specific revision (or updating to a specific
> > > revision), testing it, and then copying it, will give you that, while
> > > also avoiding a mixed-revision copy.
> >
> > That only works if you make no changes and tag the revision
> > number from your checkout or last update - or you are lucky...
> > If you make a change and commit it back, someone else may
> > have made other changes already.
>
> Your workflow is clearly different from mine. If my role is testing and
> tagging, then I will not be making changes and committing them; I'll be
> checking out a specified revision (probably from a stable branch with a
> low commit rate), testing it, and tagging it if it's good; perhaps I'll
> also update a version number and commit that. If my role is developing
> the trunk, I won't be tagging. If my role is updating a stable branch,
> I'll be aware when tagging is imminent, and try not to break it.
Yes, I'd expect the person making a candidate for testing to
apply the tag after making the last change, and the tester
to check out the tag. The workflow beyond that point might
vary depending on the product if the test fails, but if
everything checks out the tag would then be used to build
the production version. That always worked with CVS but
there weren't many other choices.
> If, in my testing role, I find that I am forced to use mixed revisions,
> I'll make that clear in the log message when the tag is committed, but
> I'd expect that to be rare (apart from updating a version number).
The person making the last change - where I want the tag applied -
may have a mixed revision in his workspace if subsequent changes
that he doesn't want at this tag point have happened at the
head where he is working by the time he needs to commit his
changes. To force everything to stay in sync without mixed
revisions, you'd have to branch just to hold this state, then
tag a state of the branch. I'm missing the value of this extra
step, since the branch and tag are fully equivalent.
If it turns out that you need additional changes here that you
don't want back on the development head you can copy a branch
from the tag. Or, depending on the nature of the changes needed
you may bail on this tag and start over with an update from
the development head.
What's the advantage of the tester pulling a branch revision
number instead of a tag?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 18 Nov 2006, Les Mikesell wrote:
> > Me too. Checking out a specific revision (or updating to a specific
> > revision), testing it, and then copying it, will give you that, while
> > also avoiding a mixed-revision copy.
>
> That only works if you make no changes and tag the revision
> number from your checkout or last update - or you are lucky...
> If you make a change and commit it back, someone else may
> have made other changes already.
Your workflow is clearly different from mine. If my role is testing and
tagging, then I will not be making changes and committing them; I'll be
checking out a specified revision (probably from a stable branch with a
low commit rate), testing it, and tagging it if it's good; perhaps I'll
also update a version number and commit that. If my role is developing
the trunk, I won't be tagging. If my role is updating a stable branch,
I'll be aware when tagging is imminent, and try not to break it.
If, in my testing role, I find that I am forced to use mixed revisions,
I'll make that clear in the log message when the tag is committed, but
I'd expect that to be rare (apart from updating a version number).
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Sat, 2006-11-18 at 02:00, Alan Barrett wrote:
> > > Fair point. But I'd still prefer to do the testing with a
> > > non-mixed-revision WC, and do an URL to URL copy.
> >
> > Why? I'd much rather have, for example, a release tag applied
> > to the actual contents of a QA working/tested copy than
> > whatever happens to have subsequently been dumped on the
> > trunk.
>
> Me too. Checking out a specific revision (or updating to a specific
> revision), testing it, and then copying it, will give you that, while
> also avoiding a mixed-revision copy.
That only works if you make no changes and tag the revision
number from your checkout or last update - or you are lucky...
If you make a change and commit it back, someone else may
have made other changes already.
> You seem to have the idea that I was advocating making tags from things
> that had not been tested. I have no idea where you got that idea. I
> advocate making tags from things that have been tested and that also
> share the same revision number.
But that might be impossible. What if other changes are happening
faster than you can test?
> > What's the point of a tag being a fully-functional copy in its own
> > right if you insist on it being a duplicate of some other revision
> > state?
>
> Simply that it makes the history easier to follow. I don't want
> somebody in the future to waste time wondering why a tag was made from
> mixed revisions instead of a single revision.
The reason would always be clear to me, since my intent with
a tag is to note the state of my workspace. I suppose you
could branch to have a second place to copy a change made
before the tag, but that makes it even harder to follow
the history when you want the change to appear back in
the trunk and doesn't really have any use of its own.
> If there really is a good reason for the tag to be made from mixed
> revisions, I think that it should be clearly documented in the commit
> log.
The point is that you shouldn't be concerned about trunk
changes that happen after you get to a point where you are
thinking about tagging. Other people making other changes
toward the next version should be a normal thing. I always
worked that way in CVS with no expectations about the
current state of HEAD and always tagging from a workspace
state. I don't see how subversion would change this expectation
in a multiuser environment since its atomic actions are still
just per-user-action. I suppose you could make a branch per user
to maintain a known state or always verify that the revision
numbers from your update/commit/tag are sequential, but I
don't see the point.
Maybe I'm missing some magic attribute of the subversion
revision numbers because CVS didn't have them. Suppose you
have a workspace checked out, changes and testing completed,
and are ready to commit and tag, but the trunk currently has
changes you don't want to incorporate. How would you handle
that, and what subsequent operations would be different
compared to just committing to the trunk with appropriate
messages then tagging from the workspace? You may end up
with trunk/HEAD in an unknown state, but that seems normal
to me for development.
> > And in any case, if you want to insist on the WC not being
> > mixed-rev at the time you tag, you have the option to commit
> > and update before tagging, then still tag from the WC. At
> > least you can then claim to know something about what you
> > just tagged.
>
> Yes, that's another way of achieving the same result.
But perhaps not desirable - you may not want those other
changes. You could branch for your changes, but unless
I'm missing the handy way to track this, it becomes harder
to follow the history than committing to the trunk in
the first place.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 18 Nov 2006, Les Mikesell wrote:
> > Fair point. But I'd still prefer to do the testing with a
> > non-mixed-revision WC, and do an URL to URL copy.
>
> Why? I'd much rather have, for example, a release tag applied
> to the actual contents of a QA working/tested copy than
> whatever happens to have subsequently been dumped on the
> trunk.
Me too. Checking out a specific revision (or updating to a specific
revision), testing it, and then copying it, will give you that, while
also avoiding a mixed-revision copy.
You seem to have the idea that I was advocating making tags from things
that had not been tested. I have no idea where you got that idea. I
advocate making tags from things that have been tested and that also
share the same revision number.
> What's the point of a tag being a fully-functional copy in its own
> right if you insist on it being a duplicate of some other revision
> state?
Simply that it makes the history easier to follow. I don't want
somebody in the future to waste time wondering why a tag was made from
mixed revisions instead of a single revision.
If there really is a good reason for the tag to be made from mixed
revisions, I think that it should be clearly documented in the commit
log.
> And in any case, if you want to insist on the WC not being
> mixed-rev at the time you tag, you have the option to commit
> and update before tagging, then still tag from the WC. At
> least you can then claim to know something about what you
> just tagged.
Yes, that's another way of achieving the same result.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Sat, 2006-11-18 at 01:02, Alan Barrett wrote:
> On Sat, 18 Nov 2006, Les Mikesell wrote:
> > Back up to the previous example where it was considered a problem
> > that a user might commit his change, then someone else might commit
> > before he copied to a tag, and copying the revision number given by
> > his commit to a tag was suggested as a solution. What if someone else
> > did their commit just before this user instead? The tag still ends up
> > including something he doesn't know about.
>
> You would have got (or will soon get) the commit email reporting the
> other person's change. You can browse the commit logs. You might or
> might not have got a "WC is out of date" error when you committed.
And the cycle may still repeat before you catch up.
> > If you make the tag from the working copy you know (and perhaps even
> > have tested...) exactly what is there.
>
> Fair point. But I'd still prefer to do the testing with a
> non-mixed-revision WC, and do an URL to URL copy.
Why? I'd much rather have, for example, a release tag applied
to the actual contents of a QA working/tested copy than
whatever happens to have subsequently been dumped on the
trunk. That is, the reason I'd want to apply a tag is
always to identify a state known to work together, not
just known to already exist at the head together. If changes
have been made locally to that working copy I'd probably
also want to commit them back to the trunk, but that's
a separate decision. If other changes have been added to the
trunk at that point, making this a mixed revision, that is
really irrelevant to the release build that I want to match
this working copy exactly. What's the point of a tag being
a fully-functional copy in its own right if you insist on
it being a duplicate of some other revision state?
And in any case, if you want to insist on the WC not being
mixed-rev at the time you tag, you have the option to commit
and update before tagging, then still tag from the WC. At
least you can then claim to know something about what you
just tagged.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 18 Nov 2006, Les Mikesell wrote:
> Back up to the previous example where it was considered a problem
> that a user might commit his change, then someone else might commit
> before he copied to a tag, and copying the revision number given by
> his commit to a tag was suggested as a solution. What if someone else
> did their commit just before this user instead? The tag still ends up
> including something he doesn't know about.
You would have got (or will soon get) the commit email reporting the
other person's change. You can browse the commit logs. You might or
might not have got a "WC is out of date" error when you committed.
> If you make the tag from the working copy you know (and perhaps even
> have tested...) exactly what is there.
Fair point. But I'd still prefer to do the testing with a
non-mixed-revision WC, and do an URL to URL copy.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-11-17 at 23:39, Alan Barrett wrote:
> > > My point is I *have* to commit the copy and the fix at the same
> > > time, else how can the tag truly reflect the point in time where the
> > > fix occurred? If I commit the fix and *then* create the tag I have
> > > two distinct commits, and there always exists the possibility of
> > > another commit sneaking in between the first and the second:
>
> You can make a note of the revision number from the first commit, and
> use that in the second commit, assuming the second commit is an URL to
> URL copy. But it's easy to forget to do that, and it's difficult to
> explain the necessity of doing that.
>
> > I don't get it. Why wouldn't you commit to the trunk (if you even want
> > the change to appear there), then copy your working copy to the tag
> > so there is no chance of anything changing that you don't want in the
> > tag.
>
> Most people have mixed-revision working copies most of the time. So
> if you create a tag by copying your WC, instead of "project/tags/foo
> is a copy of project/trunk as of revision N" you get different files
> in project/tags/foo being copies of different revisions of the
> corresponding files in project/trunk.
Exactly. If you tag a repository revision, you don't really
know that it corresponds to your working copy. How do
you know that's what you want to tag?
> If you have any uncommitted changes in your WC, copying your WC to a
> tag will copy those changes too. This is likely to be a mistake. Even
> if it's deliberate, you are likely to forget to explain it in the log
> message.
Yes, that would be a mistake. Or maybe not. If you are the
one creating the content to be tagged together and choosing
when to tag it, you should probably be the best judge of that.
You can, of course, always diff it against the trunk head if
you have any question about what you just did.
> For both the above reasons, I recommend avoiding WC to URL copies. Use
> WC to WC copies for rearranging things before you commit, or URL to URL
> copies (with explicit revision number) for creating tags or branches.
I don't see how you can atomically tag something and know what
is in the repository at the same time. Back up to the previous
example where it was considered a problem that a user might
commit his change, then someone else might commit before he
copied to a tag, and copying the revision number given by his
commit to a tag was suggested as a solution. What if someone
else did their commit just before this user instead? The tag
still ends up including something he doesn't know about. If
you make the tag from the working copy you know (and perhaps
even have tested...) exactly what is there.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Alan Barrett <ap...@cequrux.com>.
On Fri, 17 Nov 2006, Les Mikesell wrote:
> On Fri, 2006-11-17 at 13:32 -0800, Tim Hill wrote:
> > My point is I *have* to commit the copy and the fix at the same
> > time, else how can the tag truly reflect the point in time where the
> > fix occurred? If I commit the fix and *then* create the tag I have
> > two distinct commits, and there always exists the possibility of
> > another commit sneaking in between the first and the second:
You can make a note of the revision number from the first commit, and
use that in the second commit, assuming the second commit is an URL to
URL copy. But it's easy to forget to do that, and it's difficult to
explain the necessity of doing that.
> I don't get it. Why wouldn't you commit to the trunk (if you even want
> the change to appear there), then copy your working copy to the tag
> so there is no chance of anything changing that you don't want in the
> tag.
Most people have mixed-revision working copies most of the time. So
if you create a tag by copying your WC, instead of "project/tags/foo
is a copy of project/trunk as of revision N" you get different files
in project/tags/foo being copies of different revisions of the
corresponding files in project/trunk.
If you have any uncommitted changes in your WC, copying your WC to a
tag will copy those changes too. This is likely to be a mistake. Even
if it's deliberate, you are likely to forget to explain it in the log
message.
For both the above reasons, I recommend avoiding WC to URL copies. Use
WC to WC copies for rearranging things before you commit, or URL to URL
copies (with explicit revision number) for creating tags or branches.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
>
> Which is why you specify the revision you want in the copy command
> so that it doesn't matter.
>
> -- (dev A) svn commit foo.c
> => Revision 41 created
> -- (dev B) svn commit foo.c
> => Revision 42 created
> -- (dev A) svn copy -r 41 foo.c $TAGS/.....
> => Revision 43 created
> => No problem
>
Well, it's no problem for me and you, but as I noted elsewhere, this
gets much more complex for casual users. Elsewhere in this thread it
was suggested that perhaps the issue here isn't labels per-se, but
the fact that the way tags are used are overly complex for some
users, and I do tend to agree that this might well be the major issue
most casual users struggle with.
--Tim
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 17, 2006, at 15:32, Tim Hill wrote:
> On Nov 17, 2006, at 8:43 AM, Jeremy Pereira wrote:
>
>> On 17 Nov 2006, at 01:14, Tim Hill wrote:
>>
>>> Solution 2: A tag. But wait; creating a tag takes a copy
>>> operation, which is a commit. I *cannot* do my foo.c commit and
>>> then follow this with a tag operation, since these are two
>>> distinct commits. So I _must_ create the tag in my working copy
>>> and then commit both the tag and the fix at the same time. The
>>> workflow is:
>>
>> You are allowed to put a comment on an svn copy operation you
>> know. You could even use the same one as for the commit of the
>> change if you really wanted.
>
> My point is I *have* to commit the copy and the fix at the same
> time, else how can the tag truly reflect the point in time where
> the fix occurred? If I commit the fix and *then* create the tag I
> have two distinct commits, and there always exists the possibility
> of another commit sneaking in between the first and the second:
>
> -- (dev A) svn commit foo.c
> -- (dev B) svn commit foo.c
> -- (dev A) svn copy foo.c $TAGS/.....
>
> Here, dev A thinks the tag refers to the rev of foo.c he checked
> in. But it doesn't; it refers to the subsequent rev checked in by
> dev B, who "sneaked in" the update between dev A's two commits.
Which is why you specify the revision you want in the copy command so
that it doesn't matter.
-- (dev A) svn commit foo.c
=> Revision 41 created
-- (dev B) svn commit foo.c
=> Revision 42 created
-- (dev A) svn copy -r 41 foo.c $TAGS/.....
=> Revision 43 created
=> No problem
> I'm sure I'm coming over as belligerent in this discussion, which
> is unfortunate, since I don't want that. But I do get a sense of
> confirmation bias here, which is unfortunate. Subversion is a great
> product, I like it, use it, and promote it. But it has its weaker
> points, and tags, imho are one of them. Labels aren't great,
> either, but until tags get better, people like myself are going to
> continue to want labels.
Yeah, I'm sure part of the reason for this resistance is that there
are many people subscribed to this list who like myself have used
Subversion for years and understand now how it works, what the
"Subversion way" of doing things is. Most new Subversion users who
post to the list saying that something is broken have merely
misunderstood how to use Subversion properly, which is then explained
to them. And when new people come onto the list and make suggestions
that involve large changes to Subversion, the natural reaction has to
be "no, it's not necessary to make such changes; here's how we do
that with the current version of Subversion."
Developer time is scarce, and the most important changes get made
first. The developers get to decide what's important, because it's
their time. Implementing large new features (labels) is unlikely to
be deemed important enough when many will say that existing features
(tags, properties, a little scripting) can be used to achieve a
similar result. That's not to say that nobody thinks labels are
important; rather, it means that the available developers seem to
feel that other issues, such as merge tracking or true renames which
have also been requested many many many times, are more important.
As has been mentioned before, there's also the matter of defining
exactly what the hypothetical labels feature would do, how it works,
how one uses it. In this thread again (as in most of the previous
threads on the topic) there has been disagreement on this point.
Until agreement on specifications is reached, coding cannot begin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
ok, I'm throwing in the towel. I'm seeing people advocating bad
arguments in favor of the status quo and dismissing good arguments
for any form of change that might help the situation. There is too
much confirmation bias here for a useful dialog.
Fact: Tags are *not* a complete solution. If they were, the svn book
would not have example after example where rev numbers are plucked
from the log and then manually pasted back into a workflow. Either
the svn book is wrong or the tagging system is wrong. You cannot have
it both ways.
Fact: Tags *are* too complex for many non-technical (but competent)
professionals. I encounter these issues all the time. This is not a
"all you have to do is tell them foo" theoretical argument; its what
I actually *see* on a regular basis. It is as silly to argue that a
skilled graphic artist should become a subversion expert as that a
subversion dev suddenly becomes a skilled graphic artist. Neither
will happen.
Fact: I've been told, on many occasions, that Subversion is designed
as a set of fundamental primitives that avoid forcing policy onto a
workflow (which is good). Yet every time someone mentions that the
tool doesn't fit what they need the answer is they are using the
wrong workflow! If Subversion is designed for a particular workflow,
let's document it, optimize the tool for that workflow, and be done
with it.
Tags are broken/incomplete, for numerous reasons. Examples:
-- Tags are supposedly immutable. Yet the toolchain does not enforce
this. Yes, I'm aware *I* can do that with a hook, but what sort of
argument is that?
-- Tags overload the directory hierarchy metaphor. Designing a
rational directory layout for large or complex projects is a
challenge enough anyway. Having to factor in the trunk/tag/branch
structure adds very significantly to this complexity.
Well designed software/tool systems exhibit the virtue that simple
problems are solved simply and complex problems are solved using more
complex techniques, hopefully with linear scaling. As currently
designed, Subversion fails this for simple workflows (e.g. a simple
linear development cycle). It doesn't ... I repeat: it *doesn't*
work. I know that, I've watched teams trying to use it, and _wanting_
to use it, but failing because they are being forced to use overly
ornate techniques on simple problems.
At heart, Subversion is a historical database. But for some reason
there seems to be huge resistance to annotating this database in ways
that seem useful to people. Labels: not allowed! Revision properties:
disabled by default, and anyway they cannot be set during a commit,
leading to silly catch-22 issues with state. Log messages: so
overloaded parsing them is an exercise in unwarranted optimism.
As a source repository that contains the "crown jewels" of many
projects, I would have expected the ability to annotate the database
in ways that are meaningful for my workflows, and then query the
database using those annotations. Apparently, however, this is
thought of as a bad thing by the subversion community. So be it; but
the net result will be to significantly limit Subversion's
applicability.
ok, rant over: it's Friday night and I'm off for a beer! Cheers!
--Tim
On Nov 17, 2006, at 5:37 PM, Les Mikesell wrote:
> On Fri, 2006-11-17 at 18:48, Tim Hill wrote:
>>>
>>>> My point is I *have* to commit the copy and the fix at the same
>>>> time,
>>>> else how can the tag truly reflect the point in time where the fix
>>>> occurred? If I commit the fix and *then* create the tag I have two
>>>> distinct commits, and there always exists the possibility of
>>>> another
>>>> commit sneaking in between the first and the second:
>>>
>>> I don't get it. Why wouldn't you commit to the trunk (if you even
>>> want the change to appear there), then copy your working copy to
>>> the tag so there is no chance of anything changing that you don't
>>> want in the tag.
>>
>> Eh? So I have a tag that claims to reflect a change, but on closer
>> inspection the change did *not* occur at that commit? Sounds like a
>> nice confusing mess to me.
>
> The change _does_ exist in the tag. That is, the tag does
> not exist until the snapshot of the workspace is committed.
> If you want that copy you use the tag and what's in the
> trunk is not particularly relevant. As you noted in your
> example, someone else can modify the trunk any time so you
> can't trust what is there unless you have a revision number
> you know happened as a commit from a workspace in exactly
> the right state. So why not use the tag committed from
> there instead and let the trunk go about its business towards
> the next one? If you want the change on the trunk for future
> versions, commit it there too, but there is no need for that
> step to be atomic with anything.
>
>>>
>>> Call them snapshots or whatever you want. If they want to preserve
>>> an exact duplicate of their workspace, just:
>>> svn copy -m "my message goes here" . URL:/tags/my_name_for_this
>>>
>>> It's not difficult, has no issues with being atomic, and you
>>> get your choice of ever making the changes that appear here
>>> also appear in the trunk or not.
>>
>> It's also not really the point: I want a symbolic identity for a
>> commit. I don't really see how this helps.
>
> But that's what you get when you name this tag. What is the
> problem with using this tag name anywhere you might have
> used a revision number or the label that you'd like to
> refer to one?
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-11-17 at 18:48, Tim Hill wrote:
> >
> >> My point is I *have* to commit the copy and the fix at the same time,
> >> else how can the tag truly reflect the point in time where the fix
> >> occurred? If I commit the fix and *then* create the tag I have two
> >> distinct commits, and there always exists the possibility of another
> >> commit sneaking in between the first and the second:
> >
> > I don't get it. Why wouldn't you commit to the trunk (if you even
> > want the change to appear there), then copy your working copy to
> > the tag so there is no chance of anything changing that you don't
> > want in the tag.
>
> Eh? So I have a tag that claims to reflect a change, but on closer
> inspection the change did *not* occur at that commit? Sounds like a
> nice confusing mess to me.
The change _does_ exist in the tag. That is, the tag does
not exist until the snapshot of the workspace is committed.
If you want that copy you use the tag and what's in the
trunk is not particularly relevant. As you noted in your
example, someone else can modify the trunk any time so you
can't trust what is there unless you have a revision number
you know happened as a commit from a workspace in exactly
the right state. So why not use the tag committed from
there instead and let the trunk go about its business towards
the next one? If you want the change on the trunk for future
versions, commit it there too, but there is no need for that
step to be atomic with anything.
> >
> > Call them snapshots or whatever you want. If they want to preserve
> > an exact duplicate of their workspace, just:
> > svn copy -m "my message goes here" . URL:/tags/my_name_for_this
> >
> > It's not difficult, has no issues with being atomic, and you
> > get your choice of ever making the changes that appear here
> > also appear in the trunk or not.
>
> It's also not really the point: I want a symbolic identity for a
> commit. I don't really see how this helps.
But that's what you get when you name this tag. What is the
problem with using this tag name anywhere you might have
used a revision number or the label that you'd like to
refer to one?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
On Nov 17, 2006, at 2:24 PM, Les Mikesell wrote:
> On Fri, 2006-11-17 at 13:32 -0800, Tim Hill wrote:
>
>> My point is I *have* to commit the copy and the fix at the same time,
>> else how can the tag truly reflect the point in time where the fix
>> occurred? If I commit the fix and *then* create the tag I have two
>> distinct commits, and there always exists the possibility of another
>> commit sneaking in between the first and the second:
>
> I don't get it. Why wouldn't you commit to the trunk (if you even
> want the change to appear there), then copy your working copy to
> the tag so there is no chance of anything changing that you don't
> want in the tag.
Eh? So I have a tag that claims to reflect a change, but on closer
inspection the change did *not* occur at that commit? Sounds like a
nice confusing mess to me.
>
>> Are you *serious* ??? Have you ever sat down and tried to explain
>> tags to these people. It's not terminology, it's a much more complex
>> concept. Sorry, they can "get" labels, they don't "get" tags. You can
>> _call_ them labels, and they get it then, but once you start
>> explaining the *how*, they just glaze over.
>
> Call them snapshots or whatever you want. If they want to preserve
> an exact duplicate of their workspace, just:
> svn copy -m "my message goes here" . URL:/tags/my_name_for_this
>
> It's not difficult, has no issues with being atomic, and you
> get your choice of ever making the changes that appear here
> also appear in the trunk or not.
It's also not really the point: I want a symbolic identity for a
commit. I don't really see how this helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-11-17 at 13:32 -0800, Tim Hill wrote:
> My point is I *have* to commit the copy and the fix at the same time,
> else how can the tag truly reflect the point in time where the fix
> occurred? If I commit the fix and *then* create the tag I have two
> distinct commits, and there always exists the possibility of another
> commit sneaking in between the first and the second:
I don't get it. Why wouldn't you commit to the trunk (if you even
want the change to appear there), then copy your working copy to
the tag so there is no chance of anything changing that you don't
want in the tag.
> Are you *serious* ??? Have you ever sat down and tried to explain
> tags to these people. It's not terminology, it's a much more complex
> concept. Sorry, they can "get" labels, they don't "get" tags. You can
> _call_ them labels, and they get it then, but once you start
> explaining the *how*, they just glaze over.
Call them snapshots or whatever you want. If they want to preserve
an exact duplicate of their workspace, just:
svn copy -m "my message goes here" . URL:/tags/my_name_for_this
It's not difficult, has no issues with being atomic, and you
get your choice of ever making the changes that appear here
also appear in the trunk or not.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Andy Peters <de...@latke.net>.
On Nov 20, 2006, at 9:36 AM, Tim Hill wrote:
> -- The ability to create a tag (copy) at commit time in a single
> command:
>
> svn commit blah blah --tag PATH
You can already do this, although it's not a commit, it's a copy.
The assumption is that you want to tag the state of your working copy
$ svn copy . http://path/to/new/tag
It should be noted that the working copy remains on its original path
(probably trunk); TortoiseSVN helpfully reminds you of this. Also
the state of the working copy, with respect to the trunk, is still
modified, so if you commit the changes back to the trunk, obviously
the trunk differs from what's in the tag, and to be honest, I don't
understand why you'd need this.
I can think of one instance where I use the copy-WC-to-tag feature: I
do FPGAs, and it's useful to commit the final build results (binary
files used to program a configuration EPROM) to the tag, so
production people can check out the tag and get the build results.
(If they build from source, the resulting new checksum might not
match the checksum from a previous build of the same code (perhaps
changes in tools change routing, etc) and that's not good if two
"builds" should be identical.) So what I do here is
$ svn commit (assuming I've made source/etc changes; commit BEFORE
add)
$ svn add ./bin (add the build results)
$ svn copy . http://path/to/release/tag (create the tag)
$ svn revert (I don't want build results in the trunk)
If I wasn't lazy, I'd write a script to handle this. Maybe I'd call
it svncopy.
> -- The ability to use a tag as an argument to the --revision switch:
>
> svn co foo.c --revision "some-tag-path-syntax-or-other"
You can't check out an individual file, so that example isn't any
good. And if you wanted the directory that contained foo.c, you'd do
$ svn co http://path/to/foo/tags/tagIwant
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AW: Re: Is label support in future release?
Posted by Felix Gilcher <gi...@exozet.com>.
Tim Hill <ma...@comcast.net> schrieb am Montag, 20. November 2006 17:37:
> On Nov 20, 2006, at 4:37 AM, Jeremy Pereira wrote:
>
>>
>> On 17 Nov 2006, at 21:32, Tim Hill wrote:
>>
>>>>
>>>> I've seen this argument before. Are graphic artists and
>>>> technical writers really too stupid to use source code control
>>>> systems? I think your problem is in the way you are probably
>>>> trying to explain tagging. I would guess you are giving them the
>>>> CVS concept of a tag and then telling them how to implement cvs
>>>> tags in Subversion.
>>>
>>> Are you *serious* ??? Have you ever sat down and tried to explain
>>> tags to these people. It's not terminology, it's a much more
>>> complex concept. Sorry, they can "get" labels, they don't "get"
>>> tags. You can _call_ them labels, and they get it then, but once
>>> you start explaining the *how*, they just glaze over.
>>
>> Was there a reason you ignored the subsequent paragraph in my
>> post? Let me say it again: you don't *need* to teach these people
>> about tags. Tags in Subversion are just copies really. I'm sure
>> your graphic designers can understand the concept of a copy, after
>> all they probably did it all the time with the normal file system
>> in their pre-source code control days. So you just tell them that
>> when they do a release they should svn copy the trunk to a sub-
>> directory of the tags directory. Except I wouldn't call it "tags",
>> I'd call it "releases". Your graphic designers could use any
>> terminology they like for the name.
>
> "A rose by any other name...". You can call them anything you
> like ... it won't help. The tag _concept_ is more complex to
> present,
> and it's _implementation_ is more complex to explain. Do you
> have any
> experience of doing something like this? With trained, but non-
> techie, professionals?
>
I have. And apart from the problems that trained people, non-tech people have with version control in general I haven't had a single problem so far. But this is coincidential evidence and I don't doubt in any way that explaining these concepts may be difficult.
Most non-tech people don't need to know about "when was this tag created from which path and at which revision". They need to be able to check out a tag, they need to compare a tag with another one and they need to be able to create a tag. All of this is simple the way things currently are once you wrapped your mind around the "a tag is a copy" paradigm.
The best thing is not to call that thing a "tag" but just teach them "release copies are found in the folder 'tags'".
>>
>> There are problems with the subversion way, for instance tags are
>> not immutable (neither are they in cvs incidentally, tags can be
>> moved from revision to revision without even any history being
>> created); it's difficult to figure out the revision from which a
>> tag or branch was made without doing an svn log; it's almost
>> impossible to figure out which revisions have been copied to make
>> tags and branches. But to me, the way to fix these problems is to
>> fix the problems not to introduce another feature which would
>> complicate the product (unnecessarily IMHO). For instance, per
>> directory access controls would solve the immutability problem.
>>
> You have those now (per-dir access controls), so in fact it *might*
> be possible, but the implementation isn't correct, since ad
> admin has
> to "bless" a folder as a tags folder, which means just creating a
> "tags" folder is not enough; so the user has no cues from the tool
> about which "tags" folders are _really_ immutable and which should be.
To the contrary: The fact that subversion allows me to name tags any way I like gives me the freedom to call them "releases" for all non technical users out there. It allows me to build a directory structure and split tags into "dev, qa, release" if the project requires it. And I can bless them all to be immutable if I wish so.
However, using the name "tag" is a good convention and some tools (TortoiseSVN e.g.) will warn you if you try commiting to a subfolder of the tags folder.
>
> If tags were really to work for me, I would need three additional
> features:
>
> -- The ability to actually mark the tag as truly immutable, enforced
> by the tools, at create time. Something like:
>
> svn copy blah blah --immutable
You can do that. Put the proper hook in place and you don't even need the --immutable switch. You can even grant some people the permission to modifiy tags (although not recommended, but still occasionally useful). The argument that a hook is not part of subversion does not count IMO: hooks are an integral part of subversion and any subversion administrator should be capable of putting a suitable one in place. There are sufficient examples out there.
>
> -- The ability to create a tag (copy) at commit time in a single
> command:
>
> svn commit blah blah --tag PATH
You can do that, however the syntax is slightly different: 'svn copy -m"tagging this wc" . repo/tags/tagname'. This creates a tag with you desired name at commit time. There are other implications to this: you get a tag that does represent a state not in the trunk or any other branch, but this is more a problem with mixed revision working copies. I wouldn't do it but it is certainly possible.
If you imply that you command should commit to whatever path the working copy was checked out and then tag that revision: I'd not do that either as you might be tagging an untested state.
If you want the syntax to be 'svn tag' instead of 'svn copy' feel free to write a wrapper. TortoiseSVN does this btw: you get a "tag/branch" command that maps directly to a copy operation.
>
> -- The ability to use a tag as an argument to the --revision switch:
>
> svn co foo.c --revision "some-tag-path-syntax-or-other"
>
You can't, but I rarely use this (at least not with checkout). I can imagine it could be useful if you were to do lots of merging from/to branches (merge all changes from the trunk from the revision on that this branch was created). Things such as "Show all log messages in the trunk from tag_a to tag_b". However, I can live without that and it can be scripted: Write a wrapper to svn that checks wether a revision argument is a valid svn url and substitute it by the revision number the url was copied from (obtainable by svn log --stop-on-copy).
>
> Whatever -- it's not going to happen anyway since the subversion
> priests here don't need it, so ipso facto no-one else does either.
No. It's not happening because noone could write a formal spec that takes care of quite a lot of nasty corner cases and still makes life simpler. Noone volunteered to write the nessesary code either, the people developing this great great software have limited time (just like you and me probably) and decided that they regard other features as more important or more entertaining and thus will implement those first. I can not and will not hold that decision against them - their fun project is a valuable tool for me, saving me hours and hours of stupid work. Most, if not all problems I've seen in this thread are solveable in some way or another, some may seem or be a little awkward to use but you can abuse the full power of your favourite shell to make your life easier.
People here are trying to explain the reasons behind the current way things work and to help you find ways how you can solve you problems with the current featureset until perhaps sometimes label support might get implemented.
>
> --Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
regards
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
On Nov 20, 2006, at 4:37 AM, Jeremy Pereira wrote:
>
> On 17 Nov 2006, at 21:32, Tim Hill wrote:
>
>>>
>>> I've seen this argument before. Are graphic artists and
>>> technical writers really too stupid to use source code control
>>> systems? I think your problem is in the way you are probably
>>> trying to explain tagging. I would guess you are giving them the
>>> CVS concept of a tag and then telling them how to implement cvs
>>> tags in Subversion.
>>
>> Are you *serious* ??? Have you ever sat down and tried to explain
>> tags to these people. It's not terminology, it's a much more
>> complex concept. Sorry, they can "get" labels, they don't "get"
>> tags. You can _call_ them labels, and they get it then, but once
>> you start explaining the *how*, they just glaze over.
>
> Was there a reason you ignored the subsequent paragraph in my
> post? Let me say it again: you don't *need* to teach these people
> about tags. Tags in Subversion are just copies really. I'm sure
> your graphic designers can understand the concept of a copy, after
> all they probably did it all the time with the normal file system
> in their pre-source code control days. So you just tell them that
> when they do a release they should svn copy the trunk to a sub-
> directory of the tags directory. Except I wouldn't call it "tags",
> I'd call it "releases". Your graphic designers could use any
> terminology they like for the name.
"A rose by any other name...". You can call them anything you
like ... it won't help. The tag _concept_ is more complex to present,
and it's _implementation_ is more complex to explain. Do you have any
experience of doing something like this? With trained, but non-
techie, professionals?
>
> There are problems with the subversion way, for instance tags are
> not immutable (neither are they in cvs incidentally, tags can be
> moved from revision to revision without even any history being
> created); it's difficult to figure out the revision from which a
> tag or branch was made without doing an svn log; it's almost
> impossible to figure out which revisions have been copied to make
> tags and branches. But to me, the way to fix these problems is to
> fix the problems not to introduce another feature which would
> complicate the product (unnecessarily IMHO). For instance, per
> directory access controls would solve the immutability problem.
>
You have those now (per-dir access controls), so in fact it *might*
be possible, but the implementation isn't correct, since ad admin has
to "bless" a folder as a tags folder, which means just creating a
"tags" folder is not enough; so the user has no cues from the tool
about which "tags" folders are _really_ immutable and which should be.
If tags were really to work for me, I would need three additional
features:
-- The ability to actually mark the tag as truly immutable, enforced
by the tools, at create time. Something like:
svn copy blah blah --immutable
-- The ability to create a tag (copy) at commit time in a single
command:
svn commit blah blah --tag PATH
-- The ability to use a tag as an argument to the --revision switch:
svn co foo.c --revision "some-tag-path-syntax-or-other"
Whatever -- it's not going to happen anyway since the subversion
priests here don't need it, so ipso facto no-one else does either.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
No, I didn't ignore it. Frankly, you are saying "it's easy, they will
get it". Have you tried? I have, lots of times. They _don't_ get it.
And if they do get it on Monday, by Wednesday its gone again. Jeremy,
as developers we are all used to the kind of mental models and
abstractions that make this stuff second nature. But these people
have different areas of expertise, and stuff that we take for granted
are blind spots for them.
>
> Was there a reason you ignored the subsequent paragraph in my
> post? Let me say it again: you don't *need* to teach these people
> about tags. Tags in Subversion are just copies really. I'm sure
> your graphic designers can understand the concept of a copy, after
> all they probably did it all the time with the normal file system
> in their pre-source code control days. So you just tell them that
> when they do a release they should svn copy the trunk to a sub-
> directory of the tags directory. Except I wouldn't call it "tags",
> I'd call it "releases". Your graphic designers could use any
> terminology they like for the name.
>
> There are problems with the subversion way, for instance tags are
> not immutable (neither are they in cvs incidentally, tags can be
> moved from revision to revision without even any history being
> created); it's difficult to figure out the revision from which a
> tag or branch was made without doing an svn log; it's almost
> impossible to figure out which revisions have been copied to make
> tags and branches. But to me, the way to fix these problems is to
> fix the problems not to introduce another feature which would
> complicate the product (unnecessarily IMHO). For instance, per
> directory access controls would solve the immutability problem.
And that's one of the things I have proposed; to make tags more
"first class" (without breaking existing stuff) and also make them
more approachable to mere mortals. You can reference my earlier post
on this thread where I think I made my position pretty clear.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
> Well, from the viewer's perspective you're right. But IIRC there's been
> a suggestion of implementing a label by using revision properties.
> I'm no Dev, so I don't know the details, but I can remember some
> discussions about the Revision Properties being very slow because
> there's no efficient way to search through them.
This means we need to look at better ways to implement it, not that
the functionality is bad. In the end, it may come down to a dev
saying "Sorry, we programmed previous features in such a way that
there's no practical way to implement this" - I'm sure we've all done
that in the past. But nobody's said that as yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Phyrefly wrote:
>> And now think about your tag being a collection of several pages from
>> different document versions, would you still like to search for all
>> those post-it notes which could be on any page of any version of any
>> document in the pile.
>
> Are you purposefully ignoring the fact that you don't have to search
> the pile at all? It's like a magical post it note that comes when you
> call, bringing the piece of paper with it (yet remembering where in
> the pile it goes when you're done with it). Now tell me you don't
> like that idea!
Well, from the viewer's perspective you're right. But IIRC there's been
a suggestion of implementing a label by using revision properties.
I'm no Dev, so I don't know the details, but I can remember some
discussions about the Revision Properties being very slow because
there's no efficient way to search through them.
So, the implementation would come down to something like I said in my
example.
Anyways, I'm not a developer, so I'm not certain my information is still
accurate or that maybe I've misunderstood...
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
> And now think about your tag being a collection of several pages from
> different document versions, would you still like to search for all
> those post-it notes which could be on any page of any version of any
> document in the pile.
Are you purposefully ignoring the fact that you don't have to search
the pile at all? It's like a magical post it note that comes when you
call, bringing the piece of paper with it (yet remembering where in
the pile it goes when you're done with it). Now tell me you don't
like that idea!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Robert Graf-Waczenski wrote:
> For this, a very simple concept of a label would suffice:
> A text that can be associated with a revision number.
> This text must be *independent* of the commit message that was
> supplied by the committer of the change that created the
> given revision number. It is as simple as sticking a post-it
> to the correct sheet in a huge pile of paper. (Thanks to the
> other poster who used this analogy!)
Well, glad I could help... :) I meant it as a negative point, not a
positive point, but oh well.
Now imagine a repository of about 20,000 revisions (give or take a few).
Do you still like to search through the entire pile? I'd prefer a
separately stored copy.
And now think about your tag being a collection of several pages from
different document versions, would you still like to search for all
those post-it notes which could be on any page of any version of any
document in the pile.
> And, to stay with this
> analogy, removing the post-it and sticking it on a different
> paper or writing a different text on it should also be possible.
Keep in mind the danger that it's not possible to look back anymore for
this change. Which, in the case of many users, could lead to trouble.
> I don't want to have to look through all the /tags
> subfolders, then lookup the file, then open this file's
> history to determine if the offending change is there or not.
I bet your /tags directory is smaller than your /trunk and that it has
lesser revisions...
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Gerco Ballintijn <ge...@ballintijn.com>.
Robert Graf-Waczenski wrote:
> How do you achieve the following with SVN tags:
>
> I am analyzing a defect and look at the history of a
> given file in the *trunk*. This history gives me the
> revision numbers during which the given file was changed.
> It does not allow me (easily) to cross-reference a change
> in the history with what has been tagged in the past, i
> have to do this manually by checking what tag was created
> with what revision.
>
> For this, a very simple concept of a label would suffice:
> A text that can be associated with a revision number.
> This text must be *independent* of the commit message that was
> supplied by the committer of the change that created the
> given revision number. It is as simple as sticking a post-it
> to the correct sheet in a huge pile of paper. (Thanks to the
> other poster who used this analogy!) And, to stay with this
> analogy, removing the post-it and sticking it on a different
> paper or writing a different text on it should also be possible.
>
> I don't want to have to look through all the /tags
> subfolders, then lookup the file, then open this file's
> history to determine if the offending change is there or not.
>
You seem to (implicitly) assume that there is *only 1 project*
per repository. Otherwise "tags" of other project would also
show up in your list, which would at least be inconvient.
How would you distinguish between multiple projects in the
same repository? Add another naming scheme?
Greetings,
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Is label support in future release?
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
> > For this, a very simple concept of a label would suffice:
> > A text that can be associated with a revision number.
>
> For what exactly? You want to know which tag copies have been made of a
> given file? It seems like a trunk-wide label wouldn't help with that at
> all.
To tell me that "when tag X.Y was created, rev 4711 was used" and
"when tag A.B was created, rev 4819 was used" *without* taking my
eyes away from the history of a file *in the trunk*.
> To do that, you determine the range of revision numbers when the change
> was present on the trunk by doing a log of the file. Then you determine
> the tags that were created from those revisions by looking through the
> log of the entire repository. (Copies are pretty clearly marked in the
> verbose log).
That's the problem. I would have to view the log of the entire repository,
which would not be needed if the simple file log would have told me what
i need.
Moreover, if my development process does not even involve the creation
of tags, then revision labels are a simple means to later easily
determine which revision number was used for which software release.
In such a workflow, the copy information is not even present and my
example above would instead read "rev 4711 is labelled X.Y and rev 4819
is labelled A.B" and i would know that the change was introduced
between the X.Y release and the A.B release.
I can't imagine a non-trivial development process without branches, but
i think that there are a lot of projects that would do quite well without
tags if simple labels would be supported.
> I think revision labels would occasionally be helpful, but I don't see
> how they'd help for this scenario.
Hope you see better now ;-))
>
> Duncan Murdoch
>
> >
> > Robert
> >
> >
> >> -----Original Message-----
> >> From: Jeremy Pereira [mailto:jeremyp@jeremyp.net]
> >> Sent: Montag, 20. November 2006 13:37
> >> To: Tim Hill
> >> Cc: Subversion Users
> >> Subject: Re: Is label support in future release?
> >>
> >>
> >>
> >> On 17 Nov 2006, at 21:32, Tim Hill wrote:
> >>
> >> >>
> >> >> I've seen this argument before. Are graphic artists and technical
> >> >> writers really too stupid to use source code control systems? I
> >> >> think your problem is in the way you are probably trying to
> >> >> explain tagging. I would guess you are giving them the CVS
> >> >> concept of a tag and then telling them how to implement cvs tags
> >> >> in Subversion.
> >> >
> >> > Are you *serious* ??? Have you ever sat down and tried to explain
> >> > tags to these people. It's not terminology, it's a much more
> >> > complex concept. Sorry, they can "get" labels, they don't "get"
> >> > tags. You can _call_ them labels, and they get it then, but once
> >> > you start explaining the *how*, they just glaze over.
> >>
> >> Was there a reason you ignored the subsequent paragraph in my post?
> >> Let me say it again: you don't *need* to teach these people about
> >> tags. Tags in Subversion are just copies really. I'm sure your
> >> graphic designers can understand the concept of a copy, after all
> >> they probably did it all the time with the normal file system in
> >> their pre-source code control days. So you just tell them that when
> >> they do a release they should svn copy the trunk to a sub-directory
> >> of the tags directory. Except I wouldn't call it "tags", I'd call it
> >> "releases". Your graphic designers could use any terminology they
> >> like for the name.
> >>
> >> There are problems with the subversion way, for instance tags are not
> >> immutable (neither are they in cvs incidentally, tags can be moved
> >> from revision to revision without even any history being created);
> >> it's difficult to figure out the revision from which a tag or branch
> >> was made without doing an svn log; it's almost impossible to figure
> >> out which revisions have been copied to make tags and branches. But
> >> to me, the way to fix these problems is to fix the problems not to
> >> introduce another feature which would complicate the product
> >> (unnecessarily IMHO). For instance, per directory access controls
> >> would solve the immutability problem.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: users-help@subversion.tigris.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/20/2006 8:49 AM, Robert Graf-Waczenski wrote:
> How do you achieve the following with SVN tags:
>
> I am analyzing a defect and look at the history of a
> given file in the *trunk*. This history gives me the
> revision numbers during which the given file was changed.
> It does not allow me (easily) to cross-reference a change
> in the history with what has been tagged in the past, i
> have to do this manually by checking what tag was created
> with what revision.
>
> For this, a very simple concept of a label would suffice:
> A text that can be associated with a revision number.
For what exactly? You want to know which tag copies have been made of a
given file? It seems like a trunk-wide label wouldn't help with that at
all.
> This text must be *independent* of the commit message that was
> supplied by the committer of the change that created the
> given revision number. It is as simple as sticking a post-it
> to the correct sheet in a huge pile of paper. (Thanks to the
> other poster who used this analogy!) And, to stay with this
> analogy, removing the post-it and sticking it on a different
> paper or writing a different text on it should also be possible.
>
> I don't want to have to look through all the /tags
> subfolders, then lookup the file, then open this file's
> history to determine if the offending change is there or not.
To do that, you determine the range of revision numbers when the change
was present on the trunk by doing a log of the file. Then you determine
the tags that were created from those revisions by looking through the
log of the entire repository. (Copies are pretty clearly marked in the
verbose log).
I think revision labels would occasionally be helpful, but I don't see
how they'd help for this scenario.
Duncan Murdoch
>
> Robert
>
>
>> -----Original Message-----
>> From: Jeremy Pereira [mailto:jeremyp@jeremyp.net]
>> Sent: Montag, 20. November 2006 13:37
>> To: Tim Hill
>> Cc: Subversion Users
>> Subject: Re: Is label support in future release?
>>
>>
>>
>> On 17 Nov 2006, at 21:32, Tim Hill wrote:
>>
>> >>
>> >> I've seen this argument before. Are graphic artists and technical
>> >> writers really too stupid to use source code control systems? I
>> >> think your problem is in the way you are probably trying to
>> >> explain tagging. I would guess you are giving them the CVS
>> >> concept of a tag and then telling them how to implement cvs tags
>> >> in Subversion.
>> >
>> > Are you *serious* ??? Have you ever sat down and tried to explain
>> > tags to these people. It's not terminology, it's a much more
>> > complex concept. Sorry, they can "get" labels, they don't "get"
>> > tags. You can _call_ them labels, and they get it then, but once
>> > you start explaining the *how*, they just glaze over.
>>
>> Was there a reason you ignored the subsequent paragraph in my post?
>> Let me say it again: you don't *need* to teach these people about
>> tags. Tags in Subversion are just copies really. I'm sure your
>> graphic designers can understand the concept of a copy, after all
>> they probably did it all the time with the normal file system in
>> their pre-source code control days. So you just tell them that when
>> they do a release they should svn copy the trunk to a sub-directory
>> of the tags directory. Except I wouldn't call it "tags", I'd call it
>> "releases". Your graphic designers could use any terminology they
>> like for the name.
>>
>> There are problems with the subversion way, for instance tags are not
>> immutable (neither are they in cvs incidentally, tags can be moved
>> from revision to revision without even any history being created);
>> it's difficult to figure out the revision from which a tag or branch
>> was made without doing an svn log; it's almost impossible to figure
>> out which revisions have been copied to make tags and branches. But
>> to me, the way to fix these problems is to fix the problems not to
>> introduce another feature which would complicate the product
>> (unnecessarily IMHO). For instance, per directory access controls
>> would solve the immutability problem.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Is label support in future release?
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
How do you achieve the following with SVN tags:
I am analyzing a defect and look at the history of a
given file in the *trunk*. This history gives me the
revision numbers during which the given file was changed.
It does not allow me (easily) to cross-reference a change
in the history with what has been tagged in the past, i
have to do this manually by checking what tag was created
with what revision.
For this, a very simple concept of a label would suffice:
A text that can be associated with a revision number.
This text must be *independent* of the commit message that was
supplied by the committer of the change that created the
given revision number. It is as simple as sticking a post-it
to the correct sheet in a huge pile of paper. (Thanks to the
other poster who used this analogy!) And, to stay with this
analogy, removing the post-it and sticking it on a different
paper or writing a different text on it should also be possible.
I don't want to have to look through all the /tags
subfolders, then lookup the file, then open this file's
history to determine if the offending change is there or not.
Robert
> -----Original Message-----
> From: Jeremy Pereira [mailto:jeremyp@jeremyp.net]
> Sent: Montag, 20. November 2006 13:37
> To: Tim Hill
> Cc: Subversion Users
> Subject: Re: Is label support in future release?
>
>
>
> On 17 Nov 2006, at 21:32, Tim Hill wrote:
>
> >>
> >> I've seen this argument before. Are graphic artists and technical
> >> writers really too stupid to use source code control systems? I
> >> think your problem is in the way you are probably trying to
> >> explain tagging. I would guess you are giving them the CVS
> >> concept of a tag and then telling them how to implement cvs tags
> >> in Subversion.
> >
> > Are you *serious* ??? Have you ever sat down and tried to explain
> > tags to these people. It's not terminology, it's a much more
> > complex concept. Sorry, they can "get" labels, they don't "get"
> > tags. You can _call_ them labels, and they get it then, but once
> > you start explaining the *how*, they just glaze over.
>
> Was there a reason you ignored the subsequent paragraph in my post?
> Let me say it again: you don't *need* to teach these people about
> tags. Tags in Subversion are just copies really. I'm sure your
> graphic designers can understand the concept of a copy, after all
> they probably did it all the time with the normal file system in
> their pre-source code control days. So you just tell them that when
> they do a release they should svn copy the trunk to a sub-directory
> of the tags directory. Except I wouldn't call it "tags", I'd call it
> "releases". Your graphic designers could use any terminology they
> like for the name.
>
> There are problems with the subversion way, for instance tags are not
> immutable (neither are they in cvs incidentally, tags can be moved
> from revision to revision without even any history being created);
> it's difficult to figure out the revision from which a tag or branch
> was made without doing an svn log; it's almost impossible to figure
> out which revisions have been copied to make tags and branches. But
> to me, the way to fix these problems is to fix the problems not to
> introduce another feature which would complicate the product
> (unnecessarily IMHO). For instance, per directory access controls
> would solve the immutability problem.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 17 Nov 2006, at 21:32, Tim Hill wrote:
>>
>> I've seen this argument before. Are graphic artists and technical
>> writers really too stupid to use source code control systems? I
>> think your problem is in the way you are probably trying to
>> explain tagging. I would guess you are giving them the CVS
>> concept of a tag and then telling them how to implement cvs tags
>> in Subversion.
>
> Are you *serious* ??? Have you ever sat down and tried to explain
> tags to these people. It's not terminology, it's a much more
> complex concept. Sorry, they can "get" labels, they don't "get"
> tags. You can _call_ them labels, and they get it then, but once
> you start explaining the *how*, they just glaze over.
Was there a reason you ignored the subsequent paragraph in my post?
Let me say it again: you don't *need* to teach these people about
tags. Tags in Subversion are just copies really. I'm sure your
graphic designers can understand the concept of a copy, after all
they probably did it all the time with the normal file system in
their pre-source code control days. So you just tell them that when
they do a release they should svn copy the trunk to a sub-directory
of the tags directory. Except I wouldn't call it "tags", I'd call it
"releases". Your graphic designers could use any terminology they
like for the name.
There are problems with the subversion way, for instance tags are not
immutable (neither are they in cvs incidentally, tags can be moved
from revision to revision without even any history being created);
it's difficult to figure out the revision from which a tag or branch
was made without doing an svn log; it's almost impossible to figure
out which revisions have been copied to make tags and branches. But
to me, the way to fix these problems is to fix the problems not to
introduce another feature which would complicate the product
(unnecessarily IMHO). For instance, per directory access controls
would solve the immutability problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
On Nov 17, 2006, at 8:43 AM, Jeremy Pereira wrote:
>
> On 17 Nov 2006, at 01:14, Tim Hill wrote:
>
>>
>>
>> Solution 2: A tag. But wait; creating a tag takes a copy
>> operation, which is a commit. I *cannot* do my foo.c commit and
>> then follow this with a tag operation, since these are two
>> distinct commits. So I _must_ create the tag in my working copy
>> and then commit both the tag and the fix at the same time. The
>> workflow is:
>
> You are allowed to put a comment on an svn copy operation you
> know. You could even use the same one as for the commit of the
> change if you really wanted.
My point is I *have* to commit the copy and the fix at the same time,
else how can the tag truly reflect the point in time where the fix
occurred? If I commit the fix and *then* create the tag I have two
distinct commits, and there always exists the possibility of another
commit sneaking in between the first and the second:
-- (dev A) svn commit foo.c
-- (dev B) svn commit foo.c
-- (dev A) svn copy foo.c $TAGS/.....
Here, dev A thinks the tag refers to the rev of foo.c he checked in.
But it doesn't; it refers to the subsequent rev checked in by dev B,
who "sneaked in" the update between dev A's two commits.
>
>>
>>
>> Now, you and I and everyone else on this list probably understands
>> #2 perfectly. But what about tech writers? Graphic artists? At a
>> stretch, I have been able to get them to understand checkout and
>> commit, but tags? Forget it. Too much baggage. So they get it
>> wrong. Which is easier to clean-up? A bad label, or a bad branch?
>> What if they forget the copy entirely? Put the tag in the wrong
>> place?
>
> I've seen this argument before. Are graphic artists and technical
> writers really too stupid to use source code control systems? I
> think your problem is in the way you are probably trying to explain
> tagging. I would guess you are giving them the CVS concept of a
> tag and then telling them how to implement cvs tags in Subversion.
Are you *serious* ??? Have you ever sat down and tried to explain
tags to these people. It's not terminology, it's a much more complex
concept. Sorry, they can "get" labels, they don't "get" tags. You can
_call_ them labels, and they get it then, but once you start
explaining the *how*, they just glaze over.
>
>>
>> And is this *really* too much to ask? I've seen literally dozens
>> of posts asking for this feature or something very much like it.
>> Will it destroy the "purity" of subversion, or lead to feature
>> bloat? Currently, subversion has an "svn:author" property, and I
>> cannot think of any a single argument that has been leveled
>> against labels that cannot equally apply to this property, and yet
>> no-one is proposing to deprecate this "feature".
>
> Are you serious? You don't think it's important to know who
> committed a revision.
Yes, I'm serious. And yes, I think it's important to track authors.
But, to turn the tables, why isn't the author just part of the
message field? One of the arguments against labels and/or any other
more-formal commit-time meta-data seems to be "use the message
field". Well, as I said, this seems to apply equally to the
svn:author field.
I'm sure I'm coming over as belligerent in this discussion, which is
unfortunate, since I don't want that. But I do get a sense of
confirmation bias here, which is unfortunate. Subversion is a great
product, I like it, use it, and promote it. But it has its weaker
points, and tags, imho are one of them. Labels aren't great, either,
but until tags get better, people like myself are going to continue
to want labels.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 17 Nov 2006, at 01:14, Tim Hill wrote:
>
>
> Solution 2: A tag. But wait; creating a tag takes a copy operation,
> which is a commit. I *cannot* do my foo.c commit and then follow
> this with a tag operation, since these are two distinct commits. So
> I _must_ create the tag in my working copy and then commit both the
> tag and the fix at the same time. The workflow is:
You are allowed to put a comment on an svn copy operation you know.
You could even use the same one as for the commit of the change if
you really wanted.
>
>
> Now, you and I and everyone else on this list probably understands
> #2 perfectly. But what about tech writers? Graphic artists? At a
> stretch, I have been able to get them to understand checkout and
> commit, but tags? Forget it. Too much baggage. So they get it
> wrong. Which is easier to clean-up? A bad label, or a bad branch?
> What if they forget the copy entirely? Put the tag in the wrong place?
I've seen this argument before. Are graphic artists and technical
writers really too stupid to use source code control systems? I
think your problem is in the way you are probably trying to explain
tagging. I would guess you are giving them the CVS concept of a tag
and then telling them how to implement cvs tags in Subversion.
It'd be far better to come at it from the point of view of what you
are functionally trying to do with the tags. Basically, you just
want a copy of the code when it was in a specific state. In the days
before your source code control implementation to achieve this, your
graphic designers were probably just creating a copy of the directory
with their code in it and calling it a different name. e.g. source-at-
release-1.2 or whatever. Subversion tags are no harder to understand
than that. In fact they are the same as that.
In fact, don't call them tags. I always name my "tags" directory
"releases".
>
> There are many, many users of tools like subversion who are not
> deep experts in scc subtleties. All they want is a simple linear
> system they can dump stuff into and occasionally flag a
> "significant" event with a label. Tags used in this context for
> this class of user are like the proverbial sledge-hammer to crack a
> nut.
Yes tags are, but subversion copies are not. In any case, if you
need to crack a nut, use nutcrackers, don't add a nut cracking
attachment to your sledgehammer.
>
> And is this *really* too much to ask? I've seen literally dozens of
> posts asking for this feature or something very much like it. Will
> it destroy the "purity" of subversion, or lead to feature bloat?
> Currently, subversion has an "svn:author" property, and I cannot
> think of any a single argument that has been leveled against labels
> that cannot equally apply to this property, and yet no-one is
> proposing to deprecate this "feature".
Are you serious? You don't think it's important to know who
committed a revision.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-11-17 at 22:17, Tim Hill wrote:
> Understood. But in this case I would argue that the tagging feature
> set is incomplete, because if you follow this logic, it would argue
> for a system that used tags as the primary tracking tool instead of
> rev#. However, there are still rather too many places in the
> "approved" svn workflows where logs are examined to extract revnums,
> which are then used in subsequent commands. (See, for example, the
> discussions on branching in the svn book).
What workflow 'follows' a tag? If you commit your workspace to
the trunk or wherever you are working _and_ copy it to the
tag from your workspace, you know what is in the tag and you've
made the change available for the ongoing work. If other
changes are happening on the trunk, other ways of making the
tag may not end up with the same thing you have. What if
someone else commits changes before yours and you don't
update before your commit? This means your workspace may
always be in the 'mixed-rev' mode and you won't want the tag
to match any other repository state.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
Understood. But in this case I would argue that the tagging feature
set is incomplete, because if you follow this logic, it would argue
for a system that used tags as the primary tracking tool instead of
rev#. However, there are still rather too many places in the
"approved" svn workflows where logs are examined to extract revnums,
which are then used in subsequent commands. (See, for example, the
discussions on branching in the svn book).
--Tim
On Nov 17, 2006, at 4:41 PM, Gerco Ballintijn wrote:
>
> There is a significant (conceptual) difference of "tagging" state (as
> currently done in Subversion) and "tagging" revision numbers (as in
> the proposed labeling scheme, if I understand correctly). With state
> I obviously mean the contents of files and directories. Since version
> control systems (like, for instance, CVS) frequently hide this
> distinction, there is a lot of confusion about what tagging actually
> does, can do, or is supposed to do. Also among the zealous, recently
> converted Subversion enthusiasts, who promptly ignore this distinction
> and proudly claim that "Subversion tagging can do everything".
> :-/ or :-) ?
>
>
> With regards,
> Gerco Ballintijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Gerco Ballintijn <ge...@ballintijn.com>.
Tim Hill wrote:
>
> The problem, basically, is atomicity and simplicity. Why?
>
> Scenario: I fix a bug in "foo.c". I want to check it in, and annotate
> the check-in some way that is (a) meaningful and (b) can be used later
> in other svn commands to reference the file in question at the
> appropriate rev#.
>
There is a significant (conceptual) difference of "tagging" state (as
currently done in Subversion) and "tagging" revision numbers (as in
the proposed labeling scheme, if I understand correctly). With state
I obviously mean the contents of files and directories. Since version
control systems (like, for instance, CVS) frequently hide this
distinction, there is a lot of confusion about what tagging actually
does, can do, or is supposed to do. Also among the zealous, recently
converted Subversion enthusiasts, who promptly ignore this distinction
and proudly claim that "Subversion tagging can do everything".
:-/ or :-) ?
Since there is a distinction (referencing state vs a revision number),
I would say that the gain of introducing labels is there where you need
to refer to the revision by itself, as indicated earlier in the thread.
The question thus becomes which specific svn commands that need a
*revision number* (for the revision number, not the state behind it)
are you refering to in your scenario above? Diff-ing can be done using
tags (incl. merging, I think) since it uses state not the revision
numbers. So, are we only talking about showing specific ranges of log
messages? Or do I miss a significant other svn command?
The projected gain is obviously independent of the projected problems
of introducing a second namespace, questions of maintaining the history
of this second name space, and other as yet unknown problems. I have no
idea whether the project gains would ultimately outweigh the projected
problems. While I understand your frustration, if the situation was
really cut-and-dry, I suspect this feature would have been implemented
a long time ago...
But those are just my €0.02 ...
With regards,
Gerco Ballintijn.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
Yes, I think we're in sync. As a developer, my perspective is that
tags are quite elegant; they solve a problem by re-using an existing
concept in a clean, efficient, manner, very much like, say, the C
language does. But, again like C, to those less familiar with such
abstract thinking, tags are a much more difficult concept than labels
because too much of the inner workings are exposed; subversion is
_too_ primitive (in the best sense of the word) for these people. By
analogy, contrast, say, a C/C++ developer to a guy working in
JavaScript.
I think the issue, really, is that tags are only a second class
concept, i.e. a convention that most people follow but which is not
understood by the toolchain (with a few exceptions; TortoiseSVN makes
a fuss when you mutate a tag). So, in effect, tags are an interface
without an implementation, which therefore everyone (users) has to re-
implement manually.
Without looking at the complexities of implementation, what if I
could do this:
svn commit ... --tag <name>
...and have Subversion create the appropriate tag by doing a pre-
commit "svn copy" using the <name> to construct an appropriate path?
I'm skipping some horrible implementation nasties here, but imho this
_interface_ really takes the claws out of tags for many subversion
users.
--Tim
On Nov 17, 2006, at 1:19 PM, Danny van Heumen wrote:
>
> You're point here is:
> * Making a single command that can:
> * Do a commit and
> * Attach a label
> * Without having to care for a location.
>
> Am I right?
>
> This would fix:
> * Forcing people to enter location and with this the *need* to
> understand how something is stored.
> * Having to do several operations.
>
>>
> Reading this I get a very strong feeling that we need some sort of
> a "wizard" for making difficult steps easier.
> (So it's not really about the labels being wrong, it's about the
> labels being too difficult for the simple users.)
>>
>
> Well, I have to say, you did a great job explaing with a nice
> scenario.
>
> Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Tim Hill wrote:
> ok, I'm pulling my hair out on this one.
>
> The problem, basically, is atomicity and simplicity. Why?
Ok, I think I get it... I'm trying to fit this in an earlier suggested
solution (in another thread).
Actually I did already understand the problem of atomicity and
simplicity (especially simplicity is important here) but because I've
got no scenarios to measure it against, it's more difficult to
understand/explain.
> Scenario: I fix a bug in "foo.c". I want to check it in, and annotate
> the check-in some way that is (a) meaningful and (b) can be used later
> in other svn commands to reference the file in question at the
> appropriate rev#.
>
> Solution 1: Use a "magic" string in the log file at commit time. Yuck.
> The log file is already overloaded with too much magic, and anyway I
> cannot use it for (b) without a script hack. The workflow is:
>
> -- svn checkout foo.c
> -- (edit foo.c)
> -- svn commit -m "LABEL:12345 blah blah"
>
>
> Solution 2: A tag. But wait; creating a tag takes a copy operation,
> which is a commit. I *cannot* do my foo.c commit and then follow this
> with a tag operation, since these are two distinct commits. So I _must_
> create the tag in my working copy and then commit both the tag and the
> fix at the same time. The workflow is:
>
> -- svn checkout foo.c
> -- (edit foo.c)
> -- svn copy foo.c $TAGS/label12345/foo.c
> -- svn commit -m "blah blah"
>
>
> Solution 3: A label. The workflow is:
>
> -- svn checkout foo.c
> -- (edit foo.c)
> -- svn commit --label "12345" -m "blah blah"
You're point here is:
* Making a single command that can:
* Do a commit and
* Attach a label
* Without having to care for a location.
Am I right?
This would fix:
* Forcing people to enter location and with this the *need* to
understand how something is stored.
* Having to do several operations.
> Now, you and I and everyone else on this list probably understands #2
> perfectly. But what about tech writers? Graphic artists? At a stretch, I
> have been able to get them to understand checkout and commit, but tags?
> Forget it. Too much baggage. So they get it wrong. Which is easier to
> clean-up? A bad label, or a bad branch? What if they forget the copy
> entirely? Put the tag in the wrong place?
>
> There are many, many users of tools like subversion who are not deep
> experts in scc subtleties. All they want is a simple linear system they
> can dump stuff into and occasionally flag a "significant" event with a
> label. Tags used in this context for this class of user are like the
> proverbial sledge-hammer to crack a nut.
Reading this I get a very strong feeling that we need some sort of a
"wizard" for making difficult steps easier.
(So it's not really about the labels being wrong, it's about the labels
being too difficult for the simple users.)
> And is this *really* too much to ask? I've seen literally dozens of
> posts asking for this feature or something very much like it. Will it
> destroy the "purity" of subversion, or lead to feature bloat? Currently,
> subversion has an "svn:author" property, and I cannot think of any a
> single argument that has been leveled against labels that cannot equally
> apply to this property, and yet no-one is proposing to deprecate this
> "feature".
>
> --Tim
Well, I have to say, you did a great job explaing with a nice scenario.
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
ok, I'm pulling my hair out on this one.
The problem, basically, is atomicity and simplicity. Why?
Scenario: I fix a bug in "foo.c". I want to check it in, and annotate
the check-in some way that is (a) meaningful and (b) can be used
later in other svn commands to reference the file in question at the
appropriate rev#.
Solution 1: Use a "magic" string in the log file at commit time.
Yuck. The log file is already overloaded with too much magic, and
anyway I cannot use it for (b) without a script hack. The workflow is:
-- svn checkout foo.c
-- (edit foo.c)
-- svn commit -m "LABEL:12345 blah blah"
Solution 2: A tag. But wait; creating a tag takes a copy operation,
which is a commit. I *cannot* do my foo.c commit and then follow this
with a tag operation, since these are two distinct commits. So I
_must_ create the tag in my working copy and then commit both the tag
and the fix at the same time. The workflow is:
-- svn checkout foo.c
-- (edit foo.c)
-- svn copy foo.c $TAGS/label12345/foo.c
-- svn commit -m "blah blah"
Solution 3: A label. The workflow is:
-- svn checkout foo.c
-- (edit foo.c)
-- svn commit --label "12345" -m "blah blah"
Now, you and I and everyone else on this list probably understands #2
perfectly. But what about tech writers? Graphic artists? At a
stretch, I have been able to get them to understand checkout and
commit, but tags? Forget it. Too much baggage. So they get it wrong.
Which is easier to clean-up? A bad label, or a bad branch? What if
they forget the copy entirely? Put the tag in the wrong place?
There are many, many users of tools like subversion who are not deep
experts in scc subtleties. All they want is a simple linear system
they can dump stuff into and occasionally flag a "significant" event
with a label. Tags used in this context for this class of user are
like the proverbial sledge-hammer to crack a nut.
And is this *really* too much to ask? I've seen literally dozens of
posts asking for this feature or something very much like it. Will it
destroy the "purity" of subversion, or lead to feature bloat?
Currently, subversion has an "svn:author" property, and I cannot
think of any a single argument that has been leveled against labels
that cannot equally apply to this property, and yet no-one is
proposing to deprecate this "feature".
--Tim
On Nov 16, 2006, at 3:13 PM, Danny van Heumen wrote:
> Nikki Locke wrote:
>>> Workflow 1 (today): (1) enter: svn info <some-url> (2) manually
>>> scan the output for the rev#, call it X (3) enter: svn diff foo.c
>>> -r X:HEAD
>
>> OK, now I've been told the (rather obscure, IMHO) extra syntax
>> needed, how about trying Workflow 3...
>> (1) enter: svn diff --new foo.c --old <some-url>:HEAD
>
>
> Workflow 3 is about a revision range, like -r 100:200
>
> I think you need the following:
>
> 'svn diff --new foo.c --old <some-url>@HEAD'
>
> or
>
> 'svn diff --new foo.c --old <some-url>'
>
> should work too because it'll default to HEAD.
>
> Danny
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Nikki Locke wrote:
>> Workflow 1 (today):
>> (1) enter: svn info <some-url>
>> (2) manually scan the output for the rev#, call it X
>> (3) enter: svn diff foo.c -r X:HEAD
> OK, now I've been told the (rather obscure, IMHO) extra syntax needed, how
> about trying Workflow 3...
>
> (1) enter: svn diff --new foo.c --old <some-url>:HEAD
Workflow 3 is about a revision range, like -r 100:200
I think you need the following:
'svn diff --new foo.c --old <some-url>@HEAD'
or
'svn diff --new foo.c --old <some-url>'
should work too because it'll default to HEAD.
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Tim Hill wrote:
> I agree .. *getting* the rev# was not the issue, though. It was what
> I do with it when I've got it:
>
> Workflow 1 (today):
> (1) enter: svn info <some-url>
> (2) manually scan the output for the rev#, call it X
> (3) enter: svn diff foo.c -r X:HEAD
>
> Workflow 2 (with proposed feature):
> (1) enter: svn diff foo.c -r <some-url>:HEAD
OK, now I've been told the (rather obscure, IMHO) extra syntax needed, how
about trying Workflow 3...
(1) enter: svn diff --new foo.c --old <some-url>:HEAD
What's wrong with that?
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
ok, how about the section "Merging a Whole Branch to Another" in the
svn-book? Virtually every procedure described there has exactly the
kind of manual rev# hack that I'm talking about.
On Nov 15, 2006, at 4:08 PM, Danny van Heumen wrote:
> Tim Hill wrote:
>> I don't think it really matters what I'm trying to accomplish, my
>> point stands.
> At the moment I'm just trying to understand your point, I'm not
> ready to convince you yet because I don't know yet what to convince
> you of. (It was clear my earlier post was not entirely on-target so
> I'm trying to find out what target I need to hit. Whether it's you
> convincing me, or me convincing you.)
>
> Maybe you didn't notice, but I'm keeping an open mind, so if you
> have got some example cases where SVN *is* really cumbersome to
> work with, then I can understand your point.
>
>> There are a number of valid workflows that require the entry of
>> revision numbers in a command that are obtained from the output of
>> other commands. These "feedback" workflows are cumbersome when the
>> rev# has to be transferred by hand or by some script magically
>> parsing the output of an info/status/log command. If you want
>> examples, go scan the svn-book, which is full of them.
> Could you name some of those workflows? Or could you name sections
> of the svn-book which make your point clear?
>
>> The "we need labels" argument that keeps on coming up in this
>> forum is, imho, not about the lack of symbolic identifiers for
>> revision numbers: everyone points out again and again (correctly)
>> that tags do that.
> OK, this helps a little in understanding where you're going to.
>
>> It's about the need to directly *input* these revision numbers
>> symbolically into commands. Tags _don't_ do this because the last
>> step in the "feedback" loop is missing: I cannot use the tag on
>> the command line to represent, symbolically, a revision number.
>> That was what I was trying to show by my example.
> I've got this stupid feeling that we don't need more commands, but
> that we just need to input other arguments to get the same result.
> (Repository location instead of revision number)
> But like I said, I can't figure out what kind of Use Cases you're
> working with, so it's probably just my lack of imagination that
> gives me this feeling. (Probably because I haven't seen much
> company scenarios yet.)
>
> Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Tim Hill wrote:
> I don't think it really matters what I'm trying to accomplish, my point
> stands.
At the moment I'm just trying to understand your point, I'm not ready to
convince you yet because I don't know yet what to convince you of. (It
was clear my earlier post was not entirely on-target so I'm trying to
find out what target I need to hit. Whether it's you convincing me, or
me convincing you.)
Maybe you didn't notice, but I'm keeping an open mind, so if you have
got some example cases where SVN *is* really cumbersome to work with,
then I can understand your point.
> There are a number of valid workflows that require the entry of
> revision numbers in a command that are obtained from the output of other
> commands. These "feedback" workflows are cumbersome when the rev# has to
> be transferred by hand or by some script magically parsing the output of
> an info/status/log command. If you want examples, go scan the svn-book,
> which is full of them.
Could you name some of those workflows? Or could you name sections of
the svn-book which make your point clear?
> The "we need labels" argument that keeps on coming up in this forum is,
> imho, not about the lack of symbolic identifiers for revision numbers:
> everyone points out again and again (correctly) that tags do that.
OK, this helps a little in understanding where you're going to.
> It's about the need to directly *input* these revision numbers symbolically
> into commands. Tags _don't_ do this because the last step in the
> "feedback" loop is missing: I cannot use the tag on the command line to
> represent, symbolically, a revision number. That was what I was trying
> to show by my example.
I've got this stupid feeling that we don't need more commands, but that
we just need to input other arguments to get the same result.
(Repository location instead of revision number)
But like I said, I can't figure out what kind of Use Cases you're
working with, so it's probably just my lack of imagination that gives me
this feeling. (Probably because I haven't seen much company scenarios yet.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
Well, I guess we'll have to agree to disagree on this one :) And of
course I see the immense benefits of Subversion -- I wouldn't be here
otherwise!
--Tim
On Nov 15, 2006, at 10:25 PM, Ryan Schmidt wrote:
> On Nov 15, 2006, at 21:14, Tim Hill wrote:
>
>> On Nov 15, 2006, at 5:25 PM, Ryan Schmidt wrote:
>>
>>> On Nov 15, 2006, at 17:06, Tim Hill wrote:
>>>
>>>> The "we need labels" argument that keeps on coming up in this
>>>> forum is, imho, not about the lack of symbolic identifiers for
>>>> revision numbers: everyone points out again and again
>>>> (correctly) that tags do that. It's about the need to directly
>>>> *input* these revision numbers symbolically into commands. Tags
>>>> _don't_ do this because the last step in the "feedback" loop is
>>>> missing: I cannot use the tag on the command line to represent,
>>>> symbolically, a revision number. That was what I was trying to
>>>> show by my example.
>>>
>>> Well, it's not hard to write a script to determine the last
>>> changed revision given a URL:
>>>
>>> $ lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2
>>> 22210
>>>
>>> You can incorporate that into other shell commands directly; no
>>> need to transcribe any revision number by hand:
>>>
>>> $ svn log http://svn.collab.net/repos/svn \
>>> -r`lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2`
>>> --------------------------------------------------------------------
>>> ----
>>> r22210 | maxb | 2006-11-04 06:00:43 -0600 (Sat, 04 Nov 2006) | 1
>>> line
>>>
>>> Tagging release 1.4.2 with svn_version.h matching tarball.
>>> --------------------------------------------------------------------
>>> ----
>>>
>>> You can write any manner of scripts to simplify what you see as
>>> routine Subversion operations, if they are not already simple
>>> enough for you to use day to day.
>>
>> My point was portability; the script doesn't work on Windows, for
>> example.
>
> It was just a proof of concept. If Windows support is important to
> you, there are many languages that also work on Windows, including
> Perl, Python, Ruby... Pick one you like.
>
>
>> And imho "its just another little script..." on top of 100+ other
>> "just a little script" ends up breaking the camels back.
>
> Well.... all I can say is that you have to pick software knowing
> its cost. The cost of Subversion is the time it takes to learn how
> to use it, and maybe some programming expertise writing little
> scripts or, for more extensive modifications, modifying its source
> code. If you come up with something really snazzy, you contribute
> it back to the community and everybody benefits. On the other hand,
> the cost of many other version control systems is hundreds or
> thousands of dollars, perhaps even per-user license fees, plus
> perhaps consulting fees, plus the fact that it's closed-source so
> you cannot improve or change the code if you find deficiencies so
> you have to convince and pay the developers to do so.
>
> To my mind, Subversion is quite a bargain. Sure, there's room for
> improvement, but that can be said of most software, I think.
> Fortunately, with open-source software, you can participate in the
> improvement, through patches to the source code or through little
> scripts. I just mainly wanted to counter your statement that you
> "cannot use the tag on the command line to represent, symbolically,
> a revision number" since, with a little script, you can.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 15, 2006, at 21:14, Tim Hill wrote:
> On Nov 15, 2006, at 5:25 PM, Ryan Schmidt wrote:
>
>> On Nov 15, 2006, at 17:06, Tim Hill wrote:
>>
>>> The "we need labels" argument that keeps on coming up in this
>>> forum is, imho, not about the lack of symbolic identifiers for
>>> revision numbers: everyone points out again and again (correctly)
>>> that tags do that. It's about the need to directly *input* these
>>> revision numbers symbolically into commands. Tags _don't_ do this
>>> because the last step in the "feedback" loop is missing: I cannot
>>> use the tag on the command line to represent, symbolically, a
>>> revision number. That was what I was trying to show by my example.
>>
>> Well, it's not hard to write a script to determine the last
>> changed revision given a URL:
>>
>> $ lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2
>> 22210
>>
>> You can incorporate that into other shell commands directly; no
>> need to transcribe any revision number by hand:
>>
>> $ svn log http://svn.collab.net/repos/svn \
>> -r`lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2`
>> ---------------------------------------------------------------------
>> ---
>> r22210 | maxb | 2006-11-04 06:00:43 -0600 (Sat, 04 Nov 2006) | 1 line
>>
>> Tagging release 1.4.2 with svn_version.h matching tarball.
>> ---------------------------------------------------------------------
>> ---
>>
>> You can write any manner of scripts to simplify what you see as
>> routine Subversion operations, if they are not already simple
>> enough for you to use day to day.
>
> My point was portability; the script doesn't work on Windows, for
> example.
It was just a proof of concept. If Windows support is important to
you, there are many languages that also work on Windows, including
Perl, Python, Ruby... Pick one you like.
> And imho "its just another little script..." on top of 100+ other
> "just a little script" ends up breaking the camels back.
Well.... all I can say is that you have to pick software knowing its
cost. The cost of Subversion is the time it takes to learn how to use
it, and maybe some programming expertise writing little scripts or,
for more extensive modifications, modifying its source code. If you
come up with something really snazzy, you contribute it back to the
community and everybody benefits. On the other hand, the cost of many
other version control systems is hundreds or thousands of dollars,
perhaps even per-user license fees, plus perhaps consulting fees,
plus the fact that it's closed-source so you cannot improve or change
the code if you find deficiencies so you have to convince and pay the
developers to do so.
To my mind, Subversion is quite a bargain. Sure, there's room for
improvement, but that can be said of most software, I think.
Fortunately, with open-source software, you can participate in the
improvement, through patches to the source code or through little
scripts. I just mainly wanted to counter your statement that you
"cannot use the tag on the command line to represent, symbolically, a
revision number" since, with a little script, you can.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
My point was portability; the script doesn't work on Windows, for
example. And imho "its just another little script..." on top of 100+
other "just a little script" ends up breaking the camels back.
--Tim
On Nov 15, 2006, at 5:25 PM, Ryan Schmidt wrote:
>
> On Nov 15, 2006, at 17:06, Tim Hill wrote:
>
>> The "we need labels" argument that keeps on coming up in this
>> forum is, imho, not about the lack of symbolic identifiers for
>> revision numbers: everyone points out again and again (correctly)
>> that tags do that. It's about the need to directly *input* these
>> revision numbers symbolically into commands. Tags _don't_ do this
>> because the last step in the "feedback" loop is missing: I cannot
>> use the tag on the command line to represent, symbolically, a
>> revision number. That was what I was trying to show by my example.
>
> Well, it's not hard to write a script to determine the last changed
> revision given a URL:
>
> $ lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2
> 22210
>
> You can incorporate that into other shell commands directly; no
> need to transcribe any revision number by hand:
>
> $ svn log http://svn.collab.net/repos/svn \
> -r`lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2`
> ----------------------------------------------------------------------
> --
> r22210 | maxb | 2006-11-04 06:00:43 -0600 (Sat, 04 Nov 2006) | 1 line
>
> Tagging release 1.4.2 with svn_version.h matching tarball.
> ----------------------------------------------------------------------
> --
>
> You can write any manner of scripts to simplify what you see as
> routine Subversion operations, if they are not already simple
> enough for you to use day to day.
>
>
> <lastchangedrev.sh>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 15, 2006, at 17:06, Tim Hill wrote:
> The "we need labels" argument that keeps on coming up in this forum
> is, imho, not about the lack of symbolic identifiers for revision
> numbers: everyone points out again and again (correctly) that tags
> do that. It's about the need to directly *input* these revision
> numbers symbolically into commands. Tags _don't_ do this because
> the last step in the "feedback" loop is missing: I cannot use the
> tag on the command line to represent, symbolically, a revision
> number. That was what I was trying to show by my example.
Well, it's not hard to write a script to determine the last changed
revision given a URL:
$ lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2
22210
You can incorporate that into other shell commands directly; no need
to transcribe any revision number by hand:
$ svn log http://svn.collab.net/repos/svn \
-r`lastchangedrev.sh http://svn.collab.net/repos/svn/tags/1.4.2`
------------------------------------------------------------------------
r22210 | maxb | 2006-11-04 06:00:43 -0600 (Sat, 04 Nov 2006) | 1 line
Tagging release 1.4.2 with svn_version.h matching tarball.
------------------------------------------------------------------------
You can write any manner of scripts to simplify what you see as
routine Subversion operations, if they are not already simple enough
for you to use day to day.
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
I don't think it really matters what I'm trying to accomplish, my
point stands. There are a number of valid workflows that require the
entry of revision numbers in a command that are obtained from the
output of other commands. These "feedback" workflows are cumbersome
when the rev# has to be transferred by hand or by some script
magically parsing the output of an info/status/log command. If you
want examples, go scan the svn-book, which is full of them.
The "we need labels" argument that keeps on coming up in this forum
is, imho, not about the lack of symbolic identifiers for revision
numbers: everyone points out again and again (correctly) that tags do
that. It's about the need to directly *input* these revision numbers
symbolically into commands. Tags _don't_ do this because the last
step in the "feedback" loop is missing: I cannot use the tag on the
command line to represent, symbolically, a revision number. That was
what I was trying to show by my example.
--Tim
On Nov 15, 2006, at 1:25 PM, Danny van Heumen wrote:
> Tim Hill wrote:
>> I agree .. *getting* the rev# was not the issue, though. It was
>> what I do with it when I've got it:
>> Workflow 1 (today):
>> (1) enter: svn info <some-url>
>> (2) manually scan the output for the rev#, call it X
>> (3) enter: svn diff foo.c -r X:HEAD
> * I assume you mean the location of the tag? --> <some-url>
> * What are you looking for when you're looking for X exactly?
> * Sorry, but I can't follow what you want to do exactly with 3.
> Do you want to perform a 3-way diff between your WC 'foo.c' and the
> changes done between X and HEAD in the repository?
>
> Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Tim Hill wrote:
> I agree .. *getting* the rev# was not the issue, though. It was what I
> do with it when I've got it:
>
> Workflow 1 (today):
> (1) enter: svn info <some-url>
> (2) manually scan the output for the rev#, call it X
> (3) enter: svn diff foo.c -r X:HEAD
* I assume you mean the location of the tag? --> <some-url>
* What are you looking for when you're looking for X exactly?
* Sorry, but I can't follow what you want to do exactly with 3.
Do you want to perform a 3-way diff between your WC 'foo.c' and the
changes done between X and HEAD in the repository?
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
I agree .. *getting* the rev# was not the issue, though. It was what
I do with it when I've got it:
Workflow 1 (today):
(1) enter: svn info <some-url>
(2) manually scan the output for the rev#, call it X
(3) enter: svn diff foo.c -r X:HEAD
Workflow 2 (with proposed feature):
(1) enter: svn diff foo.c -r <some-url>:HEAD
In workflow (2) I'm assuming --revision has a hypothetical new
feature to accept an URL and get the rev# implied by that URL.
Questions:
1. Which workflow is shorter?
2. Which workflow is less prone to typos and errors?
3. Which workflow is easier to script/automate?
My point about labels hasn't been that they are *better* then tags;
they are not. My point is that using tags as a replacement for a
label feature is inadequate because, as currently implemented, there
is a hole in the subversion command set; the rev# *implied* by the
tag (or any other URL) is not available as an input to subversion
commands except via script hacks/magic.
(begin rant...)
I don't think this is a theoretical argument: the svn-book and
discussions groups are packed full of hints like "scan the log for
the rev# and then enter the command foobar -r rev#" etc. But manually
scanning logs, or tags etc, and then manually entering rev#s seems to
me a workflow flaw; isn't that kind of grunge work exactly what a
computer is supposed to be for.
(end rant! hehe)
--Tim
On Nov 15, 2006, at 12:17 PM, Nikki Locke wrote:
> Tim Hill wrote:
>> Stuff like back-port and integration operations. You often end up
>> needing to merge stuff where one of the rev numbers is the rev# of a
>> "well-known" revision in the repo. The "official" way to track such
>> well-known revisions is tags. OK, that's fine.
>>
>> The problem arises when I come to type the command: I need to enter
>> the rev# of the tag into a --revision switch. I can only do this two
>> ways: manually (use an svn command to get the rev# from the tag, then
>> type it), or via a bunch of shell magic (which isn't portable).
>> What's really needed here is an extension to the --revision syntax to
>> allow me to say, in effect, "the rev# implied by this URL". This
>> would give me a robust and portable way to inject the needed
>> information during the merge.
>
> Why do you need to enter the rev# number of the tag? A tag has only
> one set
> of files in it (you never commit changes to a tag), so the tag url
> is all
> you need to identify the revision of any file in the tag.
>
>
> --
> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
> http://www.trumphurst.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Tim Hill wrote:
> Stuff like back-port and integration operations. You often end up
> needing to merge stuff where one of the rev numbers is the rev# of a
> "well-known" revision in the repo. The "official" way to track such
> well-known revisions is tags. OK, that's fine.
>
> The problem arises when I come to type the command: I need to enter
> the rev# of the tag into a --revision switch. I can only do this two
> ways: manually (use an svn command to get the rev# from the tag, then
> type it), or via a bunch of shell magic (which isn't portable).
> What's really needed here is an extension to the --revision syntax to
> allow me to say, in effect, "the rev# implied by this URL". This
> would give me a robust and portable way to inject the needed
> information during the merge.
Why do you need to enter the rev# number of the tag? A tag has only one set
of files in it (you never commit changes to a tag), so the tag url is all
you need to identify the revision of any file in the tag.
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
Stuff like back-port and integration operations. You often end up
needing to merge stuff where one of the rev numbers is the rev# of a
"well-known" revision in the repo. The "official" way to track such
well-known revisions is tags. OK, that's fine.
The problem arises when I come to type the command: I need to enter
the rev# of the tag into a --revision switch. I can only do this two
ways: manually (use an svn command to get the rev# from the tag, then
type it), or via a bunch of shell magic (which isn't portable).
What's really needed here is an extension to the --revision syntax to
allow me to say, in effect, "the rev# implied by this URL". This
would give me a robust and portable way to inject the needed
information during the merge.
--Tim
On Nov 15, 2006, at 2:30 AM, Nikki Locke wrote:
> Tim Hill wrote:
>> The main issue, as I see it, is that many
>> svn workflows involve operations between different revisions in a
>> repository, but that there is no real syntax for accessing those
>> revisions symbolically.
>
> Can you give some examples of such operations?
>
> I'm relatively new to Subversion, and I'm having trouble understanding
> exactly what you would want to do that can't be done with tags.
>
> --
> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
> http://www.trumphurst.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Dmitri Colebatch <di...@colebatch.com>.
On 11/16/06, Nikki Locke <in...@trumphurst.com> wrote:
>
> Wouldn't the release be tagged in SVN (perhaps as
> /tags/production/20061115a)?
>
> Then you scan the history of that file in /tags/production/20061115a, and
> see if the fix is in there [DON'T set the "stop on copy" flag].
Yes you're right, and that's what I do. My current approach to that is to
fire up the ToroiseSVN repo-browser, browse to the file, and do as you say.
> What's the difference?
Convenience. The may simply be a limitation in IntelliJ IDEA, but when we
used CVS I could do this operation in two clicks. The above means changing
to another program, finding the file and _then_ looking for history.
Thinking further about this there's no reason I couldn't do this in IntelliJ
but I would still have the additional step of browsing to the copy of the
file in question before looking for where it was copied from.
I think the real difference is that in CVS a tag is _on_ a file, so I'm
simply saying "show me the history and I'll scan it myself to see which
version a tag is on". In SVN a tag is simply a copy, and because (afaik)
SVN has no support to seeing where a particular file has been copied _to_ it
is not possible to do the same in SVN - instead I have to look at the copy
(which I don't have at hand) and see where it was copied _from_.
cheers
dim
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Dmitri Colebatch wrote:
> We've recently migrated from cvs to svn and the single biggest thing
> I'm struggling with is the
> following scenario:
>
> I get a bug report from the field, or I want to pre-emptively check
> to see if a particular fix made it into a release (releases might be
> in QA for weeks before going out to production). In cvs, I would
> know that the tag in QA/production is "tag_20061115a". Using IntelliJ I
> would then view history of that file and I can scan down the history
> to see which version has that tag.
>
> I'm yet to figure out a nice way
> to do the same thing using svn. I've had a couple of pointers in
>
> response to an earlier enquiry but haven't really found anything that is
> as simple as the above.
Wouldn't the release be tagged in SVN (perhaps as
/tags/production/20061115a)?
Then you scan the history of that file in /tags/production/20061115a, and
see if the fix is in there [DON'T set the "stop on copy" flag].
What's the difference?
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
In this case, you are much better off using tags and the existing
features. The big push-back in the past on labels has been that they
end up being used as a poor-mans branching system in just the way you
described, and in this case I do agree with the detractors -- this is
a bad use of labels.
--Tim
On Nov 15, 2006, at 4:25 AM, Phyrefly wrote:
> I've just caught up with this thread, and there's one thing I'd
> like to add...
>
> It should be possible to create "complex labels" (the label
> "release_1" is rev 1 of Dir A, but rev 2 of Dir B (as rev 2 contained
> a bugfix in Dir B, and the start of work on release_2 in Dir A). Dir
> C might not be labeled at all at this point, as it's unnecessary in
> release 1. Then all SVN commands using a rev number could be fed a
> label instead, and would be a LOT simpler to use.
>
> One step further still, If I then found a bug in file X, I could
> branch it at label release_one, fix the bug, re-label the branch file
> as release_1, unlabel the trunk file, and merge the fix back into the
> HEAD.
>
> Now an export of "release_one" pulls rev 1 for one folder, rev 2 for
> another, ignores a third, and gets me a branched file for file X. All
> ready for release. Clearly any file should only be able to hold a
> specific lable at one revision (including branches).
>
> There's a lot less difficulty there for my end users (I am the only
> real techy in my dept, but there are lots of HTML scripters that need
> to be able to get old (stable) versions of products for new clients).
> It also means I can keep a label for latest_release, and just move it
> when I'm ready, and they don't have to change their steps at all.
> Getting them familiar enough with the way SVN works to use tag folders
> or branches is just not an option.
>
> On 15/11/06, Dmitri Colebatch <di...@colebatch.com> wrote:
>> On 11/15/06, Nikki Locke <in...@trumphurst.com> wrote:
>> > Tim Hill wrote:
>> > > The main issue, as I see it, is that many
>> > > svn workflows involve operations between different revisions in a
>> > > repository, but that there is no real syntax for accessing those
>> > > revisions symbolically.
>> >
>> > Can you give some examples of such operations?
>> >
>> > I'm relatively new to Subversion, and I'm having trouble
>> understanding
>> > exactly what you would want to do that can't be done with tags.
>>
>> We've recently migrated from cvs to svn and the single biggest
>> thing I'm
>> struggling with is the following scenario:
>>
>> I get a bug report from the field, or I want to pre-emptively
>> check to see
>> if a particular fix made it into a release (releases might be in
>> QA for
>> weeks before going out to production). In cvs, I would know that
>> the tag in
>> QA/production is "tag_20061115a". Using IntelliJ I would then
>> view history
>> of that file and I can scan down the history to see which version
>> has that
>> tag.
>>
>> I'm yet to figure out a nice way to do the same thing using svn.
>> I've had a
>> couple of pointers in response to an earlier enquiry but haven't
>> really
>> found anything that is as simple as the above.
>>
>> cheers
>> dim
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Phyrefly wrote:
> It should be possible to create "complex labels" (the label
> "release_1" is rev 1 of Dir A, but rev 2 of Dir B (as rev 2 contained
> a bugfix in Dir B, and the start of work on release_2 in Dir A). Dir
> C might not be labeled at all at this point, as it's unnecessary in
> release 1. Then all SVN commands using a rev number could be fed a
> label instead, and would be a LOT simpler to use.
As I understand it, you can do this by copying rev 1 if DirA and rev 2 or DirB to
a single tag.
> One step further still, If I then found a bug in file X, I could
> branch it at label release_one, fix the bug, re-label the branch file
> as release_1, unlabel the trunk file, and merge the fix back into the
> HEAD.
Now you have lost information. If you have a bug in the field with release_one,
you no longer know what source was used to compile it - the original release_one,
or the new one. Even if you are fairly sure it was the original release_on, you
no longer know what sources were used to compile it, as the release_one label now
referes to a different set of sources.
> Now an export of "release_one" pulls rev 1 for one folder, rev 2 for
> another, ignores a third, and gets me a branched file for file X. All
> ready for release. Clearly any file should only be able to hold a
> specific lable at one revision (including branches).
>
> There's a lot less difficulty there for my end users (I am the only
> real techy in my dept, but there are lots of HTML scripters that need
> to be able to get old (stable) versions of products for new clients).
I can't see the problem with tagging the sources needed to build each release
when it is released with a unique tag, and using that unique tag to get back
those sources when required.
> It also means I can keep a label for latest_release, and just move it
> when I'm ready, and they don't have to change their steps at all.
I can't see the problem with having a latest_release branch, and getting them to
always use the HEAD of that branch for release.
However, as a newbie to SVN, I'm agog to hear what the difficulty is.
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Joseph Mocker <mo...@fakebelieve.org>.
Tim Hill wrote:
>>
>> To all people who have heard this discussion so many times over the
>> years, and are as sick to death of it as I am, I apologize in advance
>> for prolonging this thread.
>>
> Why do you think that is?
>
> (a) We need something other than tags?
> (b) People don't "get" tags?
> (c) Users are dumb and should be ignored?
I'm somewhat of a newbie to Subversion but I do realize that the notion
of "tags" is subversion is purely logical. Subversion really has no
notion of tags. Its simply by use of copies and a logical tags/ folder
in the repository which most people happen to use do you arrive at
something resembling a tag.
Its actually pretty clever how Subversion can be made to appear to
support tags but maybe the cleverness is why people get confused by
implementing tags in Subversion. Perhaps to Tim's point.
--joe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-11-17 at 16:11 -0600, Ted Dennison wrote:
> It might be a bit easier for people to grok if the party line were
> something like "SVN doesn't really have 'tags'; it uses branches (with
> no changes on them) to accomplish the same thing". Instead of "Yeah, SVN
> has tags, but they're a bit different from everyone else's tags in the
> following seemingly arbitrary ways..."
Or "they aren't different until you commit changes to an existing one".
If it hurts, don't do it.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Ted Dennison <de...@ssd.fsi.com>.
Tim Hill wrote:
>> To all people who have heard this discussion so many times over the
>> years, and are as sick to death of it as I am, I apologize in advance
>> for prolonging this thread.
>>
> Why do you think that is?
>
> (a) We need something other than tags?
> (b) People don't "get" tags?
> (c) Users are dumb and should be ignored?
As someone fairly new to this myself, I'd guess mostly (b). It was one
of the things that took me the longest to wrap my head around (assuming
I have it right now). It doesn't help that folks here talk about tags
and branches as if they were two different things, when as near as I can
tell they aren't really.
It might be a bit easier for people to grok if the party line were
something like "SVN doesn't really have 'tags'; it uses branches (with
no changes on them) to accomplish the same thing". Instead of "Yeah, SVN
has tags, but they're a bit different from everyone else's tags in the
following seemingly arbitrary ways..."
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: AW: AW: AW: Re: Is label support in future release?
Posted by Gerco Ballintijn <ge...@ballintijn.com>.
Felix Gilcher wrote:
>
>>
>> In any case, as has been suggested elsewhere in this thread, it's
>> quite possible that what is really the issue here is that tags, in
>> their current form, are incomplete.
>>
>
> Perhaps it's the "tags are not labels but copies" paradigm that
> needs some time to get used to. I did have my hard time at first
> but really like it that way.
>
I suspected it really depends on where you come from. The reuse
of the term "tag" for the concept of a copy at the start of the
Subversion project is debatable. While it might have made the
CVS-Subversion transition more attractive to early adopters, in
the long run it leads to the problem we currently see. I would
have prefered the a term like snapshot, but the damage is done.
I really doubt that the (efficient) snapshot concept of Subversion
is inherently more complicated than the revision alias scheme,
as suggested earlier.
Regards,
Gerco.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AW: AW: AW: Re: Is label support in future release?
Posted by Felix Gilcher <gi...@exozet.com>.
Tim Hill <ma...@comcast.net> schrieb am Montag, 20. November 2006 17:28:
> On Nov 20, 2006, at 1:53 AM, Felix Gilcher wrote:
>
>>
>>> One of those arguments is "not enough people have asked for it". If
>>> everyone did as you suggest, how would enough people *ever*
>>> ask for a
>>> feature? <hehe>
>>>
>>
>> As someone else stated, this has come up on the list quite a few
>> times. Lots of people asked for it. One of the major problems is
>> that noone was able to write a specification of how this feature
>> should behave exactly (let alone how to implement it). There even
>> was a disagreement between the people that asked for labels on what
>> the term "label" implies and how this should work.
>> Writing such a specification and get a consensus that it would be a
>> worthy addition to the subversion feature set would be a first step
>> to get the feature implemented. Volunteers one step ahead please.
>> Writing the actual code or putting a bounty on that feature might
>> help as well, but as stated in the hacking guidelines even a
>> working patch is no guarantee that the feature will be accepted.
>>
>
> A perfectly valid point -- however, any discussion is bound to
> generate a lot of debate over the desired shape of a feature; I
> regard that as a sign of a vibrant active user community (which is
> good). Of course, I won't comment on the fact that, if the "label"
> feature was so ill-defined in the discussions, how were so many
> people so certain that it wasn't desirable (hehe)?
>
Well, one of the major points against tags was always that there never was a formal proposal that everyone could agree on. And a feature with undefined behaviour is per definition of questionable value ;). Having a proposal could help showing the use cases and the expected benefits - maybe this convices a majority of the devs.
See this thread alone:
- some see labels as a simple "revision alias". Probably simpler to implement than other solutions, but I doubt the usefulness (means that I can live happily without).
- others imply that a label is an alias for url@revision. Which gets you into pretty nasty corner cases if you have several projects/components in one repository...
> I'm more than happy to work up a formal proposal, and even happy to
> do the work on a patch. However, as you noted, patches don't always
> get accepted, and I would rather have at least some consensus on a
> feature before spending a lot of time working on it.
>
If a formal proposal gets accepted on the dev list, chances should be pretty high that a patch that holds to their coding standard gets accepted. Not that I may speak for the devs (not even being one), but this is the procedure laid out in the hacking file. It seems to me that a proposal (or at least a good draft) is required in this case to even achieve some consensus.
>
> In any case, as has been suggested elsewhere in this thread, it's
> quite possible that what is really the issue here is that tags, in
> their current form, are incomplete.
>
Perhaps it's the "tags are not labels but copies" paradigm that needs some time to get used to. I did have my hard time at first but really like it that way.
> --Tim
regards
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: AW: AW: Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
On Nov 20, 2006, at 1:53 AM, Felix Gilcher wrote:
>
>> One of those arguments is "not enough people have asked for it". If
>> everyone did as you suggest, how would enough people *ever*
>> ask for a
>> feature? <hehe>
>>
>
> As someone else stated, this has come up on the list quite a few
> times. Lots of people asked for it. One of the major problems is
> that noone was able to write a specification of how this feature
> should behave exactly (let alone how to implement it). There even
> was a disagreement between the people that asked for labels on what
> the term "label" implies and how this should work.
> Writing such a specification and get a consensus that it would be a
> worthy addition to the subversion feature set would be a first step
> to get the feature implemented. Volunteers one step ahead please.
> Writing the actual code or putting a bounty on that feature might
> help as well, but as stated in the hacking guidelines even a
> working patch is no guarantee that the feature will be accepted.
>
A perfectly valid point -- however, any discussion is bound to
generate a lot of debate over the desired shape of a feature; I
regard that as a sign of a vibrant active user community (which is
good). Of course, I won't comment on the fact that, if the "label"
feature was so ill-defined in the discussions, how were so many
people so certain that it wasn't desirable (hehe)?
I'm more than happy to work up a formal proposal, and even happy to
do the work on a patch. However, as you noted, patches don't always
get accepted, and I would rather have at least some consensus on a
feature before spending a lot of time working on it.
In any case, as has been suggested elsewhere in this thread, it's
quite possible that what is really the issue here is that tags, in
their current form, are incomplete.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AW: AW: Re: Is label support in future release?
Posted by Felix Gilcher <gi...@exozet.com>.
Hello,
Tim Hill <ma...@comcast.net> schrieb am Samstag, 18. November 2006 21:38:
> One of those arguments is "not enough people have asked for it". If
> everyone did as you suggest, how would enough people *ever*
> ask for a
> feature? <hehe>
>
As someone else stated, this has come up on the list quite a few times. Lots of people asked for it. One of the major problems is that noone was able to write a specification of how this feature should behave exactly (let alone how to implement it). There even was a disagreement between the people that asked for labels on what the term "label" implies and how this should work.
Writing such a specification and get a consensus that it would be a worthy addition to the subversion feature set would be a first step to get the feature implemented. Volunteers one step ahead please. Writing the actual code or putting a bounty on that feature might help as well, but as stated in the hacking guidelines even a working patch is no guarantee that the feature will be accepted.
> On Nov 18, 2006, at 6:40 AM, Felix Gilcher wrote:
>
>> Tim Hill <ma...@comcast.net> schrieb am Freitag, 17.
>> November 2006 22:41:
>>
>>>> To all people who have heard this discussion so many times over the
>>>> years, and are as sick to death of it as I am, I apologize in
>>>> advance for prolonging this thread.
>>>>
>>> Why do you think that is?
>>>
>>> (a) We need something other than tags?
>>> (b) People don't "get" tags?
>>> (c) Users are dumb and should be ignored?
>>>
>>
>> Maybe
>>
>> (d) People don't read mailinglist archives and tend to repeat the
>> same arguments over and over and over again? Label support is not
>> the only topic that gets discussed on a regular basis.
Please apologize me if this may have sounded like an insult, I'm just part of the "people that have heard this discussion...". I'm not opposed in general to this feature, but I think discussing this over and over again has no added value unless someone steps forward with a detailed spec.
regards
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: AW: Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
One of those arguments is "not enough people have asked for it". If
everyone did as you suggest, how would enough people *ever* ask for a
feature? <hehe>
On Nov 18, 2006, at 6:40 AM, Felix Gilcher wrote:
> Tim Hill <ma...@comcast.net> schrieb am Freitag, 17.
> November 2006 22:41:
>
>>> To all people who have heard this discussion so many times over the
>>> years, and are as sick to death of it as I am, I apologize in
>>> advance for prolonging this thread.
>>>
>> Why do you think that is?
>>
>> (a) We need something other than tags?
>> (b) People don't "get" tags?
>> (c) Users are dumb and should be ignored?
>>
>
> Maybe
>
> (d) People don't read mailinglist archives and tend to repeat the
> same arguments over and over and over again? Label support is not
> the only topic that gets discussed on a regular basis.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AW: Re: Is label support in future release?
Posted by Felix Gilcher <gi...@exozet.com>.
Tim Hill <ma...@comcast.net> schrieb am Freitag, 17. November 2006 22:41:
>> To all people who have heard this discussion so many times over the
>> years, and are as sick to death of it as I am, I apologize in
>> advance for prolonging this thread.
>>
> Why do you think that is?
>
> (a) We need something other than tags?
> (b) People don't "get" tags?
> (c) Users are dumb and should be ignored?
>
Maybe
(d) People don't read mailinglist archives and tend to repeat the same arguments over and over and over again? Label support is not the only topic that gets discussed on a regular basis.
> Whatever the answer, something is amiss here.
>
> --Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
regards
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
>
> To all people who have heard this discussion so many times over the
> years, and are as sick to death of it as I am, I apologize in
> advance for prolonging this thread.
>
Why do you think that is?
(a) We need something other than tags?
(b) People don't "get" tags?
(c) Users are dumb and should be ignored?
Whatever the answer, something is amiss here.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tom Mornini <tm...@infomania.com>.
On Nov 17, 2006, at 12:58 PM, Danny van Heumen wrote:
>> Nope, that's not how "mutable labels" were defined when someone
>> coined
>> the phrase earlier in this thread. The term was used to define
>> moving
>> the label from one revision to another, not changing the code in that
>> revision. The latter is a branch, and should always be treated as
>> one. The code in a "label" could never be edited, as a label is just
>> a pointer to a rev, not a copy of it that could be edited.
>> No, I said not JUST an earlier revision. It's a COPY of that earlier
>> recision, with its own potential for history, and in a different
>> location.
>
> So, in fact your main reasons for not acknowledging a copy as label
> is:
> * You can't insert an alias as revision number.
> * It has it's own history, and thus (I guess you don't really mind
> the history, just the fact that you can do more than just point to
> existing files and revisions)
> * It can potentially be used for branching purposes by modifying
> the "label"-contents and therefore it can not be a label.
>
> The latter one is important isn't it?
It is important, and it's trivial to write a pre-commit hook script
to disable commits that attempt to modify tags via pathname matching.
To all people who have heard this discussion so many times over the
years, and are as sick to death of it as I am, I apologize in advance
for prolonging this thread.
--
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
> Yes, but the joy of SVN is that we don't have to search through any
> printed out hard copies. Having real-world, hard-copy parallels
> doesn't make the SVN implementation easier or more sensible,
>
> What you're saying is that although I keep my monthly bank statements
> in a drawer to the left of my desk, in a nice neat stack, in order to
> keep my yearl-end ones accessible, I must photocopy them and put the
> copies in the drawer to my right, because I don't HAVE a post-it to
> stick on the side that would allow me to lift the year-end statement
> straight out of the stack. This means that I have a different
> work-flow to find my year-end statements to my monthly ones, and that
> I have used up a second drawer for no reason.
Well... You've got a point there too.
> See, parallels can be written either way far too easily.
Yep you're right. Well can't blame me for trying ;)
> Nope, that's not how "mutable labels" were defined when someone coined
> the phrase earlier in this thread. The term was used to define moving
> the label from one revision to another, not changing the code in that
> revision. The latter is a branch, and should always be treated as
> one. The code in a "label" could never be edited, as a label is just
> a pointer to a rev, not a copy of it that could be edited.
>
> No, I said not JUST an earlier revision. It's a COPY of that earlier
> recision, with its own potential for history, and in a different
> location.
So, in fact your main reasons for not acknowledging a copy as label is:
* You can't insert an alias as revision number.
* It has it's own history, and thus (I guess you don't really mind the
history, just the fact that you can do more than just point to existing
files and revisions)
* It can potentially be used for branching purposes by modifying the
"label"-contents and therefore it can not be a label.
The latter one is important isn't it?
Do you have any additional arguments to add?
I'm actually fishing for arguments because there've been some
discussions before (you probably guessed) and one of the discussion
actually progressed into discussing solutions instead of the problems.
(NOFI, it's just a difficult subject :D)
One of the most interesting solutions was creating a wrapper around
subversion (cross platform ofcourse) for managing "projects" and it's
labels and branches.
By using this script we can "convert" tagnames into locations without
the user even knowing. Also it should be possible to manipulate labels
like you would in CVS (and possibly other like CVS).
I.e. if we could limit the possible operations to 'copy' and 'delete'
and they would be done "underground" it would seem to be the same like
original labels. (And with history so you can look back at changes in a
label.)
> At least this is a new set of questions :)
Had to get the "feeling" :P
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
> K, then look at it this way:
> I've made a copy of a document I'm sending to a company. I keep this
> copy in a special drawer where I keep all sent-in copies.
>
> When I use your approach, I'm going to go to the large pile of document
> print-outs (versions), searching through it to find the correct version
> (with a post-it note sticking to it, saying: "I sent this copy to the
> company").
>
> While my approach says: Go to the drawer with sent-in documents. Find
> the folder labeled with the document name and the company name and get it.
>
> Comparing it to a simple real life example, I find my approach more
> logical, don't you?
Yes, but the joy of SVN is that we don't have to search through any
printed out hard copies. Having real-world, hard-copy parallels
doesn't make the SVN implementation easier or more sensible,
What you're saying is that although I keep my monthly bank statements
in a drawer to the left of my desk, in a nice neat stack, in order to
keep my yearl-end ones accessible, I must photocopy them and put the
copies in the drawer to my right, because I don't HAVE a post-it to
stick on the side that would allow me to lift the year-end statement
straight out of the stack. This means that I have a different
work-flow to find my year-end statements to my monthly ones, and that
I have used up a second drawer for no reason.
See, parallels can be written either way far too easily.
> [[[ (This was when explaining why it's too much like a branch.)
> Because it's
> possible to treat it like a branch (commit further revisions, etc) - I
> have to configure more things to stop it being used as one
> ]]]
>
> So here you say that labels shouldn't be changed. (= committing further
> revisions, which includes including files from different revisions, etc.)
Nope, that's not how "mutable labels" were defined when someone coined
the phrase earlier in this thread. The term was used to define moving
the label from one revision to another, not changing the code in that
revision. The latter is a branch, and should always be treated as
one. The code in a "label" could never be edited, as a label is just
a pointer to a rev, not a copy of it that could be edited.
> >> Please!!! Name the flexibility I'm missing because I've created a copy
> >> instead of just a label. (I seriously can't think of any.)
> >
> > You can't feed it into an svn command instead of a rev number. It's
> > no longer just an "earlier copy" of the HEAD file, it's a _different
> > URL_ - and that's not a simple adjustment for a non-techy to make.
> So you tell me that if I make a copy of a document, and put it somewhere
> else, that the contents of the copy have changed?
No, I said not JUST an earlier revision. It's a COPY of that earlier
recision, with its own potential for history, and in a different
location.
> > Seriously, I've not been asked a question that's had a different
> > answer since I chipped into this thread, ...
> Sorry, didn't mean it this way.
At least this is a new set of questions :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Fwd: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
(Brought back to the list... again)
> Where's the poison in changing a location, instead of changing a
> revision number? As far as I can tell, both mean you have to change 1
> argument of the command to a different one.
You change the rev # every time you want something other than the
head. Why change the URL instead of the rev # to get a specific rev?
It's counter-intuitive.
> Look, I understand you don't like changing the location, I really do.
> Looking at it from a CVS point-of-view it seems very strange. But other
> than that I haven't heard an argument yet. (or I have missed it, maybe I
> am blinded by SVN ideas?)
Please tell me if there's another way I can put this, so that people
will understand it:
It's more complex (too complex, in this case) for non-technical users.
> You do know that it's possible to:
> 1. Set read-only access to the 'tags' (or 'label' in this case) part of
> the repository right? You can do this for everyone except for the person
> who's going to label things.
> 2. Set a pre-commit hook (this is actually a feature, not a hack) to
> prevent *changing* subdirectories of the 'tags' directory, while
> allowing to *add* a new label.
It's USING a feature to hack another feature to feel like a missing
feature. And it still doesn't have all the functionality of the
missing feature.
> You know, it's not fair to ask for mutable labels in one part of your
> message, and complain about mutable labels in a different part of the
> same message... Do you want labels to be able to change or not???
I've never complained about mutable labels. I've possibly quoted
someone else doing so (in order to disagree with them), but I never
have.
> Please!!! Name the flexibility I'm missing because I've created a copy
> instead of just a label. (I seriously can't think of any.)
You can't feed it into an svn command instead of a rev number. It's
no longer just an "earlier copy" of the HEAD file, it's a _different
URL_ - and that's not a simple adjustment for a non-techy to make.
Seriously, I've not been asked a question that's had a different
answer since I chipped into this thread, I can't think of any new ways
to put this, so I'm not going to reply to any more questions asking me
to repeat myself. I think everyone will be happy not to have to read
the same answers again. If I ignore a post asking me to justify
something, have a look through the history of this thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
OK, as this thread is forking somewhat I'm going to start a new one
to soapbox my thinking on this issue...
--Tim
On Nov 16, 2006, at 10:11 AM, Les Mikesell wrote:
> On Thu, 2006-11-16 at 12:36 +0000, Phyrefly wrote:
>
>> This seems to be the one point everyone is not getting, or ignoring,
>> by showing, in some cases, very complex solutions to the use cases I
>> am suggesting would be made easier by labels.
>
> I think you are approaching this from the wrong angle. Branches
> are the 'subversion' way of doing things and replacing them
> probably isn't going to happen. On the other hand, there are
> some things that awkward to do with branches that perhaps
> could be made easier. Why not go through a use case and propose
> changes in branch/merge handling that would help with the
> problem. That will then help both the case where a name for
> a revision would work and also the ones where you really
> do need the branch (that is, you need things in there that
> you don't ever want to appear on the trunk).
>
>>>
>>> It's not always a marble if it's round, only if you would play
>>> like you
>>> would with a marble.
>>
>> It's a branch if it's implemented like a branch. Because it's
>> possible to treat it like a branch (commit further revisions, etc)
>> - I
>> have to configure more things to stop it being used as one.
>
> I'm not sure it is subversion's job to prevent your users from doing
> something you don't like. Can you concentrate on letting them do
> the operations that need to be done? That is, if using a branch
> is a problem, how can a branch be made less of a problem?
>
>> It's a
>> hack, basically, to make a branch feel a little like a label... in
>> the
>> implementation, it's a branch, with everything that implies. But
>> most
>> importantly, it's NOT just a link to a prior revision, it's a copy of
>> that revision in another place in the repo, meaning that it loses
>> some
>> of the flexibility that a label would have.
>
> If what you want is just
> myname=351
> where 351 is a repository revision number, put that in a file
> committed
> to the head of the trunk where you can always find the current copy.
> Grab it through the web interface if you don't want the trappings of
> a head checkout just to read it.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-11-16 at 12:36 +0000, Phyrefly wrote:
> This seems to be the one point everyone is not getting, or ignoring,
> by showing, in some cases, very complex solutions to the use cases I
> am suggesting would be made easier by labels.
I think you are approaching this from the wrong angle. Branches
are the 'subversion' way of doing things and replacing them
probably isn't going to happen. On the other hand, there are
some things that awkward to do with branches that perhaps
could be made easier. Why not go through a use case and propose
changes in branch/merge handling that would help with the
problem. That will then help both the case where a name for
a revision would work and also the ones where you really
do need the branch (that is, you need things in there that
you don't ever want to appear on the trunk).
> >
> > It's not always a marble if it's round, only if you would play like you
> > would with a marble.
>
> It's a branch if it's implemented like a branch. Because it's
> possible to treat it like a branch (commit further revisions, etc) - I
> have to configure more things to stop it being used as one.
I'm not sure it is subversion's job to prevent your users from doing
something you don't like. Can you concentrate on letting them do
the operations that need to be done? That is, if using a branch
is a problem, how can a branch be made less of a problem?
> It's a
> hack, basically, to make a branch feel a little like a label... in the
> implementation, it's a branch, with everything that implies. But most
> importantly, it's NOT just a link to a prior revision, it's a copy of
> that revision in another place in the repo, meaning that it loses some
> of the flexibility that a label would have.
If what you want is just
myname=351
where 351 is a repository revision number, put that in a file committed
to the head of the trunk where you can always find the current copy.
Grab it through the web interface if you don't want the trappings of
a head checkout just to read it.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Phyrefly wrote:
>> Where's the poison in changing a location, instead of changing a
>> revision number? As far as I can tell, both mean you have to change 1
>> argument of the command to a different one.
>
> You change the rev # every time you want something other than the
> head. Why change the URL instead of the rev # to get a specific rev?
> It's counter-intuitive.
K, then look at it this way:
I've made a copy of a document I'm sending to a company. I keep this
copy in a special drawer where I keep all sent-in copies.
When I use your approach, I'm going to go to the large pile of document
print-outs (versions), searching through it to find the correct version
(with a post-it note sticking to it, saying: "I sent this copy to the
company").
While my approach says: Go to the drawer with sent-in documents. Find
the folder labeled with the document name and the company name and get it.
Comparing it to a simple real life example, I find my approach more
logical, don't you?
>> You do know that it's possible to:
>> 1. Set read-only access to the 'tags' (or 'label' in this case) part of
>> the repository right? You can do this for everyone except for the person
>> who's going to label things.
>> 2. Set a pre-commit hook (this is actually a feature, not a hack) to
>> prevent *changing* subdirectories of the 'tags' directory, while
>> allowing to *add* a new label.
>
> It's USING a feature to hack another feature to feel like a missing
> feature. And it still doesn't have all the functionality of the
> missing feature.
>
>> You know, it's not fair to ask for mutable labels in one part of your
>> message, and complain about mutable labels in a different part of the
>> same message... Do you want labels to be able to change or not???
>
> I've never complained about mutable labels. I've possibly quoted
> someone else doing so (in order to disagree with them), but I never
> have.
Actually you have, when you said this:
[[[ (This was in naming examples of complex labels.)
At it's simplest, yes. There are some more complex ideas being
suggested too, which I think would be a benefit (complex labels,
mutable labels etc), but this is the simplest version, yes.
]]]
[[[ (This was when explaining why it's too much like a branch.)
Because it's
possible to treat it like a branch (commit further revisions, etc) - I
have to configure more things to stop it being used as one
]]]
So here you say that labels shouldn't be changed. (= committing further
revisions, which includes including files from different revisions, etc.)
>> Please!!! Name the flexibility I'm missing because I've created a copy
>> instead of just a label. (I seriously can't think of any.)
>
> You can't feed it into an svn command instead of a rev number. It's
> no longer just an "earlier copy" of the HEAD file, it's a _different
> URL_ - and that's not a simple adjustment for a non-techy to make.
So you tell me that if I make a copy of a document, and put it somewhere
else, that the contents of the copy have changed?
> Seriously, I've not been asked a question that's had a different
> answer since I chipped into this thread, ...
Sorry, didn't mean it this way.
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Hi,
>>> My users check out latest code from trunk, and an earlier version from
>>> trunk. Why should they be forced to create and use a branch (which is
>>> what a tag is) just to make a revision number easier to remember
>>> (which is all a tag should be)?
>> So you say this:
>> It's purely an alias for a revision number, like (myLabel == 213) and
>> nothing more?
>
> At it's simplest, yes. There are some more complex ideas being
> suggested too, which I think would be a benefit (complex labels,
> mutable labels etc), but this is the simplest version, yes.
This is exactly the point where things get dangerous, and the point why
developers haven't implemented a label(-like) solution yet.
*at it's simplest, yes*: So implementing something like this would make
your life better, but you would prefer a more complete solution, right?
Complex labels: multiple revisions? multiple directories? both?
Mutable/unmutable labels: so, not just a label, but a label you can move
arround if necessary. With history? (Because you would want to know if
someone decided to move a label to a different version of the file.)
Existing files/new files: Add new files when you're creating your label.
With/without modifications: Being able to store modified files in your
label?
Do you mean these kind of complex ideas?
>
>> Do you mind explaining a Use Case for this? (I'm sorry, you probably
>> already mentioned one, but I can't find it...)
>
> The most simple example is the export of a labelled version of a
> project in the repo. Tim has presented a lot of more involved ones.
> The general case is being able to replace an arbitrary number with a
> sensible word in all other svn commands (without changing the URL, the
> command syntax or anything else, see my first point)
Where's the poison in changing a location, instead of changing a
revision number? As far as I can tell, both mean you have to change 1
argument of the command to a different one.
Look, I understand you don't like changing the location, I really do.
Looking at it from a CVS point-of-view it seems very strange. But other
than that I haven't heard an argument yet. (or I have missed it, maybe I
am blinded by SVN ideas?)
> It's a branch if it's implemented like a branch. Because it's
> possible to treat it like a branch (commit further revisions, etc) - I
> have to configure more things to stop it being used as one. It's a
> hack, basically, to make a branch feel a little like a label... in the
> implementation, it's a branch, with everything that implies.Also it's
You do know that it's possible to:
1. Set read-only access to the 'tags' (or 'label' in this case) part of
the repository right? You can do this for everyone except for the person
who's going to label things.
2. Set a pre-commit hook (this is actually a feature, not a hack) to
prevent *changing* subdirectories of the 'tags' directory, while
allowing to *add* a new label.
You know, it's not fair to ask for mutable labels in one part of your
message, and complain about mutable labels in a different part of the
same message... Do you want labels to be able to change or not???
> But most
> importantly, it's NOT just a link to a prior revision, it's a copy of
> that revision in another place in the repo, meaning that it loses some
> of the flexibility that a label would have.
Please!!! Name the flexibility I'm missing because I've created a copy
instead of just a label. (I seriously can't think of any.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
(Previous mail sent directly, brought back to the list:)
> Phyrefly wrote:
> >> What's the big difference?
> >
> > I repeat (again): ease of use for the non-technical.
> k, I understand, this is probably the most convincing and best
> understood argument (I guess).
This seems to be the one point everyone is not getting, or ignoring,
by showing, in some cases, very complex solutions to the use cases I
am suggesting would be made easier by labels.
>> My users check out latest code from trunk, and an earlier version from
>> trunk. Why should they be forced to create and use a branch (which is
>> what a tag is) just to make a revision number easier to remember
>> (which is all a tag should be)?
> So you say this:
> It's purely an alias for a revision number, like (myLabel == 213) and
> nothing more?
At it's simplest, yes. There are some more complex ideas being
suggested too, which I think would be a benefit (complex labels,
mutable labels etc), but this is the simplest version, yes.
> Do you mind explaining a Use Case for this? (I'm sorry, you probably
> already mentioned one, but I can't find it...)
The most simple example is the export of a labelled version of a
project in the repo. Tim has presented a lot of more involved ones.
The general case is being able to replace an arbitrary number with a
sensible word in all other svn commands (without changing the URL, the
command syntax or anything else, see my first point)
>> As to the 8 different versions of "label" - each suggestion you gave
>> is a limitation on a global solution, not a different solution
>> entirely.
>
>True, I was only suggesting that with this many people and this many
>different versioning systems it's (almost) impossible to find a solution
>which fits into everyone's expectations.
>> If it was deemed important to limit this functionality
>> programatically, it would be easy enough to add a few lines to the
>> config file.
>> ([allow_complex_tags=true/false][allow_mutable_tags=true/false]
> > etc. If any history was needed for labels at all, it would merely be
> > a list of revision numbers, hardly much overhead at all, especially
> > when compared to maintaining a new branch.
> Please don't look at it as a branch. It's only a branch if you use it
> like a branch.
>
> It's not always a marble if it's round, only if you would play like you
> would with a marble.
It's a branch if it's implemented like a branch. Because it's
possible to treat it like a branch (commit further revisions, etc) - I
have to configure more things to stop it being used as one. It's a
hack, basically, to make a branch feel a little like a label... in the
implementation, it's a branch, with everything that implies. But most
importantly, it's NOT just a link to a prior revision, it's a copy of
that revision in another place in the repo, meaning that it loses some
of the flexibility that a label would have.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Phyrefly wrote:
> It should be possible to create "complex labels" (the label
> "release_1" is rev 1 of Dir A, but rev 2 of Dir B (as rev 2 contained
> a bugfix in Dir B, and the start of work on release_2 in Dir A). Dir
> C might not be labeled at all at this point, as it's unnecessary in
> release 1. Then all SVN commands using a rev number could be fed a
> label instead, and would be a LOT simpler to use.
Good example.
This is exactly why the SVN developers haven't implemented a (CVS like)
tag/label yet. (This is my opinion and has nothing what-so-ever to do
with the developers.)
Some people would like to see a label to be an alias for a revision
number, while others would like to see it as a collection of different
files with different versions... Some would like to keep a history
record, others want to just move the tag, and some say a tag isn't
mutable at all.
(And there are more differences where this came from :P... and the same
goes for branching concepts :-s)
So, I figure that you have the following options:
1. Find at least 8 synonyms for a 'label' (like 'alias' and 'tag') and
give every synonym a slightly different functionality. (Which will
result in a rather large command line help text.)
2. Think of an alternative argument for svn that incorporates all these
functions and is easier in use than the current approach. Suggest this
to the developers and if thoroughly thought of I'm sure they will accept.
3. Create a new program or scripts which 'wraps' around svn's tools,
which gives you an easier way to work with tags, whilst not changing the
internal functionality of Subversion.
As far as I could tell, there wasn't a solution that solves all the
different concepts of a tag (or branch for that matter) and that's why
they haven't implemented any yet.
On the other hand... when someone makes a copy of a release report and
stores it in a different drawer, everyone agrees. But if one is
suggested to copy the current state of a program for safe keeping (a tag
for a program that is about to be released) to a different location,
then it's difficult/a lot of work/etc.
Looking at it from a different point-of-view:
SVN Devvers give you:
1. parameter to point to your tag --> that is the repository url which
points to the tags directory inside the repository.
People want:
1. parameter to point to your tag --> instead of using '-r <rev#>' you
use '-r <tagname>'.
What's the big difference?
Danny
(I'm going to follow this thread with great interest, and I don't mean
to insult anyone or so with this email message.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Is label support in future release?
Posted by Trent Nelson <tn...@onresolve.com>.
Phyrefly [mailto:phyrefly.phyre@gmail.com] wrote:
> I agree, tags provide all the needed features, but they're far too
> complex (and expensive in terms of ease-of-use if nothing else) to be
> used as labels. I would like to be able to label my repo at the point
> I do a release, but I have no intention of treating it as a branch,
> just a convenient way of getting that code back.
The 'label' use cases you identify there can easily be achieved by tags;
perhaps the roadblock is more of a mental one than functional one. Why
don't you:
> svn ls
branches/
tags/
trunk/
labels/
release_1_product_A/
release_1_product_B_go_live/
Granted, I personally don't see why you wouldn't want to use tags here,
but I can accept the fact that there's a large group of
non-svn-developers for which a tag will never feel like a label. You
could lock the labels/ dir such that it can only be modified by a
certain account (I lock tags/ with a 'releasemgr' account even if it's
just me using the repo; that way I know I'll never be able to commit
things accidentally to tagged branches. Same could apply with labels.)
> It should be possible to create "complex labels" (the label
> "release_1" is rev 1 of Dir A, but rev 2 of Dir B (as rev 2 contained
> a bugfix in Dir B, and the start of work on release_2 in Dir A). Dir
> C might not be labeled at all at this point, as it's unnecessary in
> release 1.
I think this is a pretty common requirement, at least it is for us. We
approach it by having another top level svn dir called 'views'; the
contents of which are simply empty directories with svn:externals set,
e.g.
> svn ls
branches/
tags/
httpd-2.0.48.1/
httpd-2.2.3.1/
httpd-2.2.4.1/
perl-5.8.4.1/
perl-5.8.8.1/
myproduct-bar-1.0/
myproduct-bar-1.1/
mytool-foo-2.1/
mytool-foo-2.2/
trunk/
views/
2.0.x/
2.0.x-trent-dev/
latest_release/
> svn proplist -v views/latest_release
svn:externals:
common/perl https://svn.mycompany.com/repo/tags/perl-5.8.8.1
common/httpd https://svn.mycompany.com/repo/tags/httpd-2.0.48.1
products/foo https://svn.mycompany.com/repo/tags/myproduct-bar-1.0
tools/bar https://svn.mycompany.com/repo/tags/mytool-foo-2.1
This way, developers/users check out views and don't really need to know
anything about tags/branches/labels.
> There's a lot less difficulty there for my end users (I am the only
> real techy in my dept, but there are lots of HTML scripters that need
> to be able to get old (stable) versions of products for new clients).
> It also means I can keep a label for latest_release, and just move it
> when I'm ready, and they don't have to change their steps at all.
If you used an approach like the one above, you'd have a view called
'latest_release' that's composed of the relevant svn paths, then get
your HTML scripters to check out that particular view.
When you want to move the 'latest_release' on, just edit the
svn:externals for that particular folder. This'll be automatically
picked up when your users do svn update.
We rely on this approach heavily to 'compose' our working copies of all
the relevant tags/branches of the underlying components and it works
like an absolute charm.
Trent.
--
http://www.onresolve.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
I've just caught up with this thread, and there's one thing I'd like to add...
It should be possible to create "complex labels" (the label
"release_1" is rev 1 of Dir A, but rev 2 of Dir B (as rev 2 contained
a bugfix in Dir B, and the start of work on release_2 in Dir A). Dir
C might not be labeled at all at this point, as it's unnecessary in
release 1. Then all SVN commands using a rev number could be fed a
label instead, and would be a LOT simpler to use.
One step further still, If I then found a bug in file X, I could
branch it at label release_one, fix the bug, re-label the branch file
as release_1, unlabel the trunk file, and merge the fix back into the
HEAD.
Now an export of "release_one" pulls rev 1 for one folder, rev 2 for
another, ignores a third, and gets me a branched file for file X. All
ready for release. Clearly any file should only be able to hold a
specific lable at one revision (including branches).
There's a lot less difficulty there for my end users (I am the only
real techy in my dept, but there are lots of HTML scripters that need
to be able to get old (stable) versions of products for new clients).
It also means I can keep a label for latest_release, and just move it
when I'm ready, and they don't have to change their steps at all.
Getting them familiar enough with the way SVN works to use tag folders
or branches is just not an option.
On 15/11/06, Dmitri Colebatch <di...@colebatch.com> wrote:
> On 11/15/06, Nikki Locke <in...@trumphurst.com> wrote:
> > Tim Hill wrote:
> > > The main issue, as I see it, is that many
> > > svn workflows involve operations between different revisions in a
> > > repository, but that there is no real syntax for accessing those
> > > revisions symbolically.
> >
> > Can you give some examples of such operations?
> >
> > I'm relatively new to Subversion, and I'm having trouble understanding
> > exactly what you would want to do that can't be done with tags.
>
> We've recently migrated from cvs to svn and the single biggest thing I'm
> struggling with is the following scenario:
>
> I get a bug report from the field, or I want to pre-emptively check to see
> if a particular fix made it into a release (releases might be in QA for
> weeks before going out to production). In cvs, I would know that the tag in
> QA/production is "tag_20061115a". Using IntelliJ I would then view history
> of that file and I can scan down the history to see which version has that
> tag.
>
> I'm yet to figure out a nice way to do the same thing using svn. I've had a
> couple of pointers in response to an earlier enquiry but haven't really
> found anything that is as simple as the above.
>
> cheers
> dim
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
There are only two answers, neither very good: use tags or use some
kind semi-formal syntax in the log message.
--Tim
On Nov 15, 2006, at 2:56 AM, Dmitri Colebatch wrote:
> On 11/15/06, Nikki Locke <in...@trumphurst.com> wrote:
> Tim Hill wrote:
> > The main issue, as I see it, is that many
> > svn workflows involve operations between different revisions in a
> > repository, but that there is no real syntax for accessing those
> > revisions symbolically.
>
> Can you give some examples of such operations?
>
> I'm relatively new to Subversion, and I'm having trouble understanding
> exactly what you would want to do that can't be done with tags.
>
> We've recently migrated from cvs to svn and the single biggest
> thing I'm struggling with is the following scenario:
>
> I get a bug report from the field, or I want to pre-emptively check
> to see if a particular fix made it into a release (releases might
> be in QA for weeks before going out to production). In cvs, I
> would know that the tag in QA/production is "tag_20061115a". Using
> IntelliJ I would then view history of that file and I can scan down
> the history to see which version has that tag.
>
> I'm yet to figure out a nice way to do the same thing using svn.
> I've had a couple of pointers in response to an earlier enquiry but
> haven't really found anything that is as simple as the above.
>
> cheers
> dim
>
>
Re: Is label support in future release?
Posted by Mark Kempster <ma...@kempster.org>.
On Wed, 15 Nov 2006, Dmitri Colebatch wrote:
> On 11/15/06, Nikki Locke <in...@trumphurst.com> wrote:
> >
> > Tim Hill wrote:
> > > The main issue, as I see it, is that many
> > > svn workflows involve operations between different revisions in a
> > > repository, but that there is no real syntax for accessing those
> > > revisions symbolically.
> >
> > Can you give some examples of such operations?
> >
> > I'm relatively new to Subversion, and I'm having trouble understanding
> > exactly what you would want to do that can't be done with tags.
>
>
> We've recently migrated from cvs to svn and the single biggest thing I'm
> struggling with is the following scenario:
>
> I get a bug report from the field, or I want to pre-emptively check to see
> if a particular fix made it into a release (releases might be in QA for
> weeks before going out to production). In cvs, I would know that the tag in
> QA/production is "tag_20061115a". Using IntelliJ I would then view history
> of that file and I can scan down the history to see which version has that
> tag.
I'm working with a similar setup - perhaps this can help.
Short answer: We drop the bug number in the subversion checkin log (as
opposed to a label), then search for it through 'svn log' or trac - don't
worry, it's not as painful as it sounds.
Our bug-tracking system that's completely unhooked from svn, so the
documentation about what-commit-fixes-what-bug are basically manual.
That documentation is in the form of a checkin comment - there's a
pre-commit hook that 'helps' the developer with the format of the
first line of the checkin comment- it ends up looking like
BUG #1234 - Fixed the hoojiwhatsit on the thingamajig
multi-line comments as needed
Re: Is label support in future release?
Posted by Dmitri Colebatch <di...@colebatch.com>.
On 11/15/06, Nikki Locke <in...@trumphurst.com> wrote:
>
> Tim Hill wrote:
> > The main issue, as I see it, is that many
> > svn workflows involve operations between different revisions in a
> > repository, but that there is no real syntax for accessing those
> > revisions symbolically.
>
> Can you give some examples of such operations?
>
> I'm relatively new to Subversion, and I'm having trouble understanding
> exactly what you would want to do that can't be done with tags.
We've recently migrated from cvs to svn and the single biggest thing I'm
struggling with is the following scenario:
I get a bug report from the field, or I want to pre-emptively check to see
if a particular fix made it into a release (releases might be in QA for
weeks before going out to production). In cvs, I would know that the tag in
QA/production is "tag_20061115a". Using IntelliJ I would then view history
of that file and I can scan down the history to see which version has that
tag.
I'm yet to figure out a nice way to do the same thing using svn. I've had a
couple of pointers in response to an earlier enquiry but haven't really
found anything that is as simple as the above.
cheers
dim
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Tim Hill wrote:
> The main issue, as I see it, is that many
> svn workflows involve operations between different revisions in a
> repository, but that there is no real syntax for accessing those
> revisions symbolically.
Can you give some examples of such operations?
I'm relatively new to Subversion, and I'm having trouble understanding
exactly what you would want to do that can't be done with tags.
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Dmitri Colebatch <di...@colebatch.com>.
And I suppose the real problem with this "solution" is that tools won't have
native support for it, which at the end of the day is the problem we face
currently.... hmmmm.
On 11/15/06, Tim Hill <dr...@comcast.net> wrote:
>
> That's pretty much the idea, except that what you really want is to be
> able to get the rev# implied by a tag, which can be done with some even more
> ugly shell hacking. The downside of course is this is platform dependent and
> very much a second-class citizen.
>
> --Tim
>
> On Nov 14, 2006, at 3:45 PM, Dmitri Colebatch wrote:
>
> Hi Tim et al,
>
> On 11/15/06, Tim Hill <dr...@comcast.net> wrote:
> >
> > Revision properties could fulfill much of this need, but the
> > implementation of these is (imho) broken, since they cannot be set
> > atomically as part of a commit (which, btw, would also make them far
> > less dangerous).
>
>
> I'm a relative newbie to svn but had wondered about this approach. Has
> anyone done any work on this? Whilst just about all of svn is convention
> rather than rule, adding a property to a bunch of files seems like a pretty
> good alternative. In addition to this, given that the revision numbers are
> for the entire repository all I'd need is one place in svn that "hacked in"
> the "tags". I had even thought of having one file that contained my tags...
> something like:
>
> svn://server/module/trunk
> svn://server/module/taginfo.txt
>
> I could then write a script that used a combination of svn info, some
> parsing of the output (is there a better way to simply get the current
> revision?), and svn commit. These three would then give me a taginfo.txtfile that looked something like:
>
> [tagname]=[revision]
>
> When I want to export, I'd then have another script that did the
> reverse... something like:
>
> svn ex -r `svn cat svn://server/module/taginfo.txt | grep [tagname]`
> svn://server/module/trunk
>
> Having given this all of 5 minutes thought it seems like a fairly workable
> "convention". Of course native support would be better, but from what I
> gather that aint going to happen. Having said all this, I don't want to be
> doing something that other people think is a bad idea and so would
> appreciate feedback on this.
>
> cheers
> dim
>
>
>
>
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
That's pretty much the idea, except that what you really want is to
be able to get the rev# implied by a tag, which can be done with some
even more ugly shell hacking. The downside of course is this is
platform dependent and very much a second-class citizen.
--Tim
On Nov 14, 2006, at 3:45 PM, Dmitri Colebatch wrote:
> Hi Tim et al,
>
> On 11/15/06, Tim Hill <dr...@comcast.net> wrote:
> Revision properties could fulfill much of this need, but the
> implementation of these is (imho) broken, since they cannot be set
> atomically as part of a commit (which, btw, would also make them far
> less dangerous).
>
> I'm a relative newbie to svn but had wondered about this approach.
> Has anyone done any work on this? Whilst just about all of svn is
> convention rather than rule, adding a property to a bunch of files
> seems like a pretty good alternative. In addition to this, given
> that the revision numbers are for the entire repository all I'd
> need is one place in svn that "hacked in" the "tags". I had even
> thought of having one file that contained my tags... something like:
>
> svn://server/module/trunk
> svn://server/module/taginfo.txt
>
> I could then write a script that used a combination of svn info,
> some parsing of the output (is there a better way to simply get the
> current revision?), and svn commit. These three would then give me
> a taginfo.txt file that looked something like:
>
> [tagname]=[revision]
>
> When I want to export, I'd then have another script that did the
> reverse... something like:
>
> svn ex -r `svn cat svn://server/module/taginfo.txt | grep
> [tagname]` svn://server/module/trunk
>
> Having given this all of 5 minutes thought it seems like a fairly
> workable "convention". Of course native support would be better,
> but from what I gather that aint going to happen. Having said all
> this, I don't want to be doing something that other people think is
> a bad idea and so would appreciate feedback on this.
>
> cheers
> dim
Re: Is label support in future release?
Posted by Dmitri Colebatch <di...@colebatch.com>.
Hi Tim et al,
On 11/15/06, Tim Hill <dr...@comcast.net> wrote:
>
> Revision properties could fulfill much of this need, but the
> implementation of these is (imho) broken, since they cannot be set
> atomically as part of a commit (which, btw, would also make them far
> less dangerous).
I'm a relative newbie to svn but had wondered about this approach. Has
anyone done any work on this? Whilst just about all of svn is convention
rather than rule, adding a property to a bunch of files seems like a pretty
good alternative. In addition to this, given that the revision numbers are
for the entire repository all I'd need is one place in svn that "hacked in"
the "tags". I had even thought of having one file that contained my tags...
something like:
svn://server/module/trunk
svn://server/module/taginfo.txt
I could then write a script that used a combination of svn info, some
parsing of the output (is there a better way to simply get the current
revision?), and svn commit. These three would then give me a
taginfo.txtfile that looked something like:
[tagname]=[revision]
When I want to export, I'd then have another script that did the reverse...
something like:
svn ex -r `svn cat svn://server/module/taginfo.txt | grep [tagname]`
svn://server/module/trunk
Having given this all of 5 minutes thought it seems like a fairly workable
"convention". Of course native support would be better, but from what I
gather that aint going to happen. Having said all this, I don't want to be
doing something that other people think is a bad idea and so would
appreciate feedback on this.
cheers
dim
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
This issue has been discussed at length a number of times (by myself
and others) on this list. The main issue, as I see it, is that many
svn workflows involve operations between different revisions in a
repository, but that there is no real syntax for accessing those
revisions symbolically. Yes, I can create a tag to remind me of a
significant point in the repo, but I cannot express the concept of
"the revision represented by this tag" directly in a subversion
command. Instead I have to extract this revision manually, then
manually transfer it as a number to a subversion command. Yes, this
can be hacked into a script, but that adds complexity and fragility
that I would like to avoid.
So, lacking any way to recover the information implied by a tag, the
natural alternative is to ask for symbolic labels, since the
assumption is that these would be able to be input into (say) the --
revision switch as an alternate to a number or date.
Revision properties could fulfill much of this need, but the
implementation of these is (imho) broken, since they cannot be set
atomically as part of a commit (which, btw, would also make them far
less dangerous).
--Tim
On Nov 14, 2006, at 11:30 AM, Nikki Locke wrote:
> Phyrefly wrote:
>> I agree, tags provide all the needed features, but they're far too
>> complex (and expensive in terms of ease-of-use if nothing else) to be
>> used as labels. I would like to be able to label my repo at the
>> point
>> I do a release, but I have no intention of treating it as a branch,
>> just a convenient way of getting that code back. Currently I'm using
>> the datestamp on my release log as a means of doing an export of a
>> particular point in the repo's history.
>
> What's the ease-of-use difference between creating a tag, and
> creating a "label"?
>
> What command would you run to create a label?
> How does that compare with the command you would run to create a tag?
>
> --
> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
> http://www.trumphurst.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Nikki Locke <in...@trumphurst.com>.
Phyrefly wrote:
> I agree, tags provide all the needed features, but they're far too
> complex (and expensive in terms of ease-of-use if nothing else) to be
> used as labels. I would like to be able to label my repo at the point
> I do a release, but I have no intention of treating it as a branch,
> just a convenient way of getting that code back. Currently I'm using
> the datestamp on my release log as a means of doing an export of a
> particular point in the repo's history.
What's the ease-of-use difference between creating a tag, and creating a "label"?
What command would you run to create a label?
How does that compare with the command you would run to create a tag?
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Phyrefly <ph...@gmail.com>.
I agree, tags provide all the needed features, but they're far too
complex (and expensive in terms of ease-of-use if nothing else) to be
used as labels. I would like to be able to label my repo at the point
I do a release, but I have no intention of treating it as a branch,
just a convenient way of getting that code back. Currently I'm using
the datestamp on my release log as a means of doing an export of a
particular point in the repo's history.
It's the one feature missing from SVN as far as I'm concerned.
Richard.
On 14/11/06, Tim Hill <dr...@comcast.net> wrote:
> If by "label" you mean some sort of name tag for a rev#, then you're out of
> luck -- it's been debated here several times and met with strong resistance
> by the svn developers, who feel that tags provide all the needed features.
>
> --Tim
>
>
> On Nov 9, 2006, at 4:05 PM, Tim Liu wrote:
> Folks,
>
> I have seen dev forum talk about label support:
>
> http://subversion.tigris.org/servlets/BrowseList?windowSize=50&by=thread&from=180403&to=180403&count=23&first=1&list=dev&selectedPage=1
>
> I don't see it in roadmap:
> http://subversion.tigris.org/roadmap.html#release-planning
>
> Is it still in plan for future release?
>
> thx
>
> Tim
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
If by "label" you mean some sort of name tag for a rev#, then you're
out of luck -- it's been debated here several times and met with
strong resistance by the svn developers, who feel that tags provide
all the needed features.
--Tim
On Nov 9, 2006, at 4:05 PM, Tim Liu wrote:
> Folks,
>
> I have seen dev forum talk about label support:
>
> http://subversion.tigris.org/servlets/BrowseList?
> windowSize=50&by=thread&from=180403&to=180403&count=23&first=1&list=de
> v&selectedPage=1
>
> I don't see it in roadmap:
> http://subversion.tigris.org/roadmap.html#release-planning
>
> Is it still in plan for future release?
>
> thx
>
> Tim
>
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
I don't see a problem, since a peg-rev is just another URL; an alias
for another "coordinate" in the repo.
Am I missing something?
--Tim
On Nov 15, 2006, at 1:20 PM, Andy Peters wrote:
> So, how do peg revisions fit into all of this?
>
> -a
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by John Rouillard <ro...@renesys.com>.
On Thu, Nov 16, 2006 at 07:02:10PM +0000, Phyrefly wrote:
> On 16/11/06, John Rouillard <ro...@renesys.com> wrote:
> > label: a property on a file svn:label associated with the newest
> > revision of a file. Multiple labels can be set using
> > propedit. The label property is a label name followed by the
> > file revisions (repository revision of the changes to the
> > file) that should be labeled. E.G.
> >
> > PRODUCTION: 2 20
> > TEST2:2 10
> >
> > would make 'svn up -r PRODUCTION' extract the contents of the
> > file at repository revision 20.
> >
> > So I have the following labeled entries in trunk/:
> >
> > file rev labels latest changed revision
> > foo1 2 PRODUCTION 20
> > 2 TEST
> >
> > foo2 22 PRODUCTION 22
> >
> > a/foo3 10 PRODUCTION 13
> >
> > b/foo4 10 TEST 13
> >
> > [...]
> >where "rev" is the newest revision for the label.
> >It might be possible to do this using un-versioned properties as well
> >to set the label list on the latest version.
> >
> >Ideally, I could just use --revprop svn:label:PRODUCTION on any
> >arbitrary revision of a file and svn would automatically choose the
> >latest revision with the tag. If I needed to get to an earlier state,
> >I would just use a peg revision in the update/checkout URL.
> >
> >However it would require traversing down the version tree for the file
> >and might be expensive. Also you can change the revprop's and screw up
> >the ability to retreive a prior release using a peg revision.
> The only thing I'd add is this: If you're going to keep any history at
> all for labels (which I'm not sure is necessary) - then the date of
> the change should probably be kept too. This will tell you when
> PRODUCTION became rev 20, as opposed to rev 2, for example. (and thus
> which rev was given to a client that you did a build for on a specific
> date).
Hence arguing for it being a versioned property of the file so
you get a datestamp automatically.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by John Rouillard <ro...@renesys.com>.
On Wed, Nov 15, 2006 at 02:54:25PM -0800, Tim Hill wrote:
> Er ... not true. A peg revision is an URL of the form URL@REV. It is
> normally used to indicate a "starting point" for looking for
> something, such as when a file has been renamed/moved or even
> deleted. It can be used with -r, in which case the peg-rev is used as
> a start point and the repo is then searched (normally backwards) for
> the specified revision.
Labels would solve (I think) the problem I am having with maintaining
a cherry picked tree of loosely coupled files (for details see prior
emails by me in the previous week in the archives). Also this
mechanism would allow me to pull prior labeled states using a peg
revision.
Ok, so here is a dumb idea for labels:
label: a property on a file svn:label associated with the newest
revision of a file. Multiple labels can be set using
propedit. The label property is a label name followed by the
file revisions (repository revision of the changes to the
file) that should be labeled. E.G.
PRODUCTION: 2 20
TEST2:2 10
would make 'svn up -r PRODUCTION' extract the contents of the
file at repository revision 20.
So I have the following labeled entries in trunk/:
file rev labels latest changed revision
foo1 2 PRODUCTION 20
2 TEST
foo2 22 PRODUCTION 22
a/foo3 10 PRODUCTION 13
b/foo4 10 TEST 13
where "rev" is the newest revision for the label.
Now I want to pull all of the files/revisions marked
PRODUCTION. Assuming I have checked out the trunk, performing an
svn up -r PRODUCTION
should retrieve three files (foo1, foo2, a/foo3) at the "rev" revision
and populate my workspace and delete b/foo4 since it doesn't have the
production tag.
Now I verify that foo1 at revision 20 can be used, so I do a:
svn propedit svn:label foo1
and change "PRODUCTION:2 to PRODUCTION:2 20" and check it in creating
revision 24.
Now when I update my working copy, foo1 is updated to the version at
rev 20 not rev 2 (always takes the highest revision for the label). If
I want to get a prior label set, I can use peg revisions (bet you were
wondering why I am adding to this thread):
svn co -r PRODUCTION svn:.../trunk@23
which should check out revision 2 of foo1 again.
It might be possible to do this using un-versioned properties as well
to set the label list on the latest version.
Ideally, I could just use --revprop svn:label:PRODUCTION on any
arbitrary revision of a file and svn would automatically choose the
latest revision with the tag. If I needed to get to an earlier state,
I would just use a peg revision in the update/checkout URL.
However it would require traversing down the version tree for the file
and might be expensive. Also you can change the revprop's and screw up
the ability to retreive a prior release using a peg revision.
Does this lead to ideas on anybody's part?
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
Tim Hill wrote:
> Er ... not true. A peg revision is an URL of the form URL@REV. It is
> normally used to indicate a "starting point" for looking for something,
> such as when a file has been renamed/moved or even deleted. It can be
> used with -r, in which case the peg-rev is used as a start point and the
> repo is then searched (normally backwards) for the specified revision.
>
> HEAD, PREV etc are just special hard-wired names for "significant"
> revisions.
Yeah, you're right, my bad.
In the past I've looked this up 3 times already, but somehow I just can
seem to remember correctly :(
Tnx for correcting me,
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Tim Hill <dr...@comcast.net>.
Er ... not true. A peg revision is an URL of the form URL@REV. It is
normally used to indicate a "starting point" for looking for
something, such as when a file has been renamed/moved or even
deleted. It can be used with -r, in which case the peg-rev is used as
a start point and the repo is then searched (normally backwards) for
the specified revision.
HEAD, PREV etc are just special hard-wired names for "significant"
revisions.
--Tim
On Nov 15, 2006, at 1:28 PM, Danny van Heumen wrote:
>> Andy Peters wrote:
>>> So, how do peg revisions fit into all of this?
>>> -a
> Peg revisions are predefined revision aliases used in Subversion,
> but you can't create custom peg revisions.
>
> Some pegs that are available: HEAD, PREV, and some more :P. But
> they are 'given' and can not be changed, and none can be added.
>
> (At least that is what I understand.)
>
> Danny
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Danny van Heumen <da...@hccnet.nl>.
> Andy Peters wrote:
>> So, how do peg revisions fit into all of this?
>>
>> -a
Peg revisions are predefined revision aliases used in Subversion, but
you can't create custom peg revisions.
Some pegs that are available: HEAD, PREV, and some more :P. But they are
'given' and can not be changed, and none can be added.
(At least that is what I understand.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is label support in future release?
Posted by Andy Peters <de...@latke.net>.
So, how do peg revisions fit into all of this?
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org