You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com> on 2007/08/24 17:32:24 UTC
Similating "label" feature in Subversion?
I have an interesting situation where labels (rather than "tags") would
be handy. I want to identify a certain revision (r31) as a suitable
rollback point during testing. Since we're testing the functionality of
Subversion, we don't really care about the revisions after this stable
starting point. We care about whether the behavior is as expected, and
we might want to rollback all changes to r31 to start fresh.
Now, this is just the current need. I can forsee where we might want to
identify particular revisions for the future. For example "We created
branch XYZ at this revision". Of course, these labels would have to be
something we can easilly see with a report or by looking at a property
history on the repository.
Do any of you know an efficient way to get this functionality? I took a
quick stab at creating a custom property called "label" but it doesn't
seem to be what I need. When I update it, the original is then hidden
in history and I can't really find it in a repository browser or a
property list in my workspace.
--
David Bicking
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Similating "label" feature in Subversion?
Posted by Jason Winnebeck <jp...@rit.edu>.
-----Original Message-----
From: Bicking, David (HHoldings, IT)
[mailto:David.Bicking@thehartford.com]
4. We cannot look at the history of a file (in a codeline) and see which
labels it received, and do a compare between labels. I am unsure how we
could get the same result in Subversion w/o much manual work...
-----------------
This is possible is some circumstances if you reverse your viewpoint by
resolving by tag and then file rather than file then tag. In a system
like SourceSafe, typically we make labels based on release. Then when
you view file history you can see the labels to find out which version
of the file was in what version.
In subversion, to make releases we make a tag. But now you have a file
dir/xyz.c in your code, and you want to see changes made in xyz.c
between version 1.0 and version 2.0. So, you find the file xyz.c in
tags/1.0 and tags/2.0, and there you can do the differences with 'svn
diff'
This works as well as history-between-labels if you typically tag your
whole project at a time (which is typical with a release model). It
doesn't allow you to easily simulate labels on a single file in time,
and it doesn't work well when the file's location changed between
releases, since you'll have to search manually. So, my advice is based
mostly on the fact that when people want to compare labels what they
really want to do is compare between product releases, and the typical
way of doing this is easily done in SVN.
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Similating "label" feature in Subversion?
Posted by "Miller, Eric" <Er...@amd.com>.
> If we use Subversion we simply have to come to grips with a few
points:
>
> 1. If we tag liberally, we will have a very large repository directory
> (but fairly small usage of repository space).
Or you can simply refine your tagging methodology and create categories
of tags, user tagging areas, etc. The implementation is very open-ended
and flexible.
> 2. "rollback" as usually understood does not exist in Subversion. A
> similar outcome is achieved by a kind of "commit in reverse order".
> Unlike "traditional rollback", this preserves all changes (in both
> directions) in history and is slightly more complicated to execute.
Yes - removing revisions is not easy. But when you get used to it you
will probably agree that reverse-merge is really the "right" way of
doing things.
> 3. To tag individual files, we select them and copy them into a tag
> folder. Hopefully, we would not have reason to do this, because it
would
> require manual duplication of the folder tree (create folder), and I'm
not
> sure if this would be manageable or useful in the repository long
term.
Or use svn-mucc (multi url copy client) to marshal all of your mkdirs
and copyfroms into a single commit. Generally speaking, however, it is
sufficient just to tag the current state of your working copy.
> 4. We cannot look at the history of a file (in a codeline) and see
which
> labels it received, and do a compare between labels. I am unsure how
we
> could get the same result in Subversion w/o much manual work. We
would
> have to determine which tags contained the file and at what revision,
then
> initiate a comparison on the appropriate codeline based on revision
> numbers. Clunky at best, impossible at worst. In fact, this means we
> have to make sure we associate individual tags very closely to their
> branches, which I guess is a best practice anyway. If the label were
> associated with the file, rather than representing a copy of said
file,
> there would be no danger of any label being listed with the wrong
branch,
> as they are attached to the codeline in question.
You've hit the nail on the head there, with the exception of "determine
which tags contained the file and at what revision" - the url pointing
to the tagged file already implies the revision it was tagged at, just
like if you had made a physical copy of the file at that revision. The
annoying bit is the multiple svn ls queries that have to happen.
If "copyto" data was saved in the repository as well as "copyfrom" then
I think this issue would be put to rest. Seems like it kinda ties in
with merge tracking a bit, if you consider a copy merging a complete
file into an empty one :D
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Similating "label" feature in Subversion?
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Jean-Claude Antonio [mailto:jcantonio@arcetis.com]
> There are 2 ways you can achieve this.
>
> With Branches
> projects
> /trunk
> /branches
> /2007-05-01; Mini-effort on feature A
> /2007-05-15; Mini-effort on feature B
> /tags
>
> You can always determine the branchpoints (the revision of
> the creation of you branch) of your branches :
> by using svn log --stop-on-copy
> so you can use the svn update -r branchpoint
>
> Or if you want you can create Tags.
> - Create your branch, then create you tag (make it then RO by
> a script or with authorization)
> - Start develop in your branch.
> Remember that svn copy is cheap.
------------8<----------------
> then use svn co path_to_tag_name to go back to.
>
> Jean-Claude
>
> Bicking, David (HHoldings, IT) a écrit :
> >
> > Thank you for your reply. What you suggest is to use the
> revision. However, I am talking about labeling a revision
> with a human-readable, searchable text fragment. Some SCM
> tools permit labels on individual files at specific
> revisions, though these systems usually keep revisions per
> file, not per repository.
AND
> From: Dave Grundgeiger [mailto:dave.grundgeiger@codenouveau.com]
> Hi David. I think I'm missing something. If you create a tag
> at each of the above milestones, giving the tag the desired
> human-readable name, then your tags folder contains the list
> that you show above, and you can revert to any tag at will.
> Is there additional behavior that you need?
>
> Dave
Thanks guys. I think it is safe to say that what I seek is not available and probably won't be added to Subversion, but the existing techniques, as you describe, get the basic job done. Dave, to your point, "revert to any tag at will", is different as you describe it from what I was seeking. What actually happens in your revert is a "reverse-merge" as I call it, which puts at the tip the same code that was in the tag. I was looking at it from a different angle: right-click the label, choose "rollback", and essentially delete all revisions after that label in the _codeline_ that was labeled.
If we use Subversion we simply have to come to grips with a few points:
1. If we tag liberally, we will have a very large repository directory (but fairly small usage of repository space).
2. "rollback" as usually understood does not exist in Subversion. A similar outcome is achieved by a kind of "commit in reverse order". Unlike "traditional rollback", this preserves all changes (in both directions) in history and is slightly more complicated to execute.
3. To tag individual files, we select them and copy them into a tag folder. Hopefully, we would not have reason to do this, because it would require manual duplication of the folder tree (create folder), and I'm not sure if this would be manageable or useful in the repository long term.
4. We cannot look at the history of a file (in a codeline) and see which labels it received, and do a compare between labels. I am unsure how we could get the same result in Subversion w/o much manual work. We would have to determine which tags contained the file and at what revision, then initiate a comparison on the appropriate codeline based on revision numbers. Clunky at best, impossible at worst. In fact, this means we have to make sure we associate individual tags very closely to their branches, which I guess is a best practice anyway. If the label were associated with the file, rather than representing a copy of said file, there would be no danger of any label being listed with the wrong branch, as they are attached to the codeline in question.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How large can a subversion repository be?
Posted by Marc Haisenko <ha...@comdasys.com>.
On Tuesday 28 August 2007 17:33, KNUTSON Stacy wrote:
>
> Thanks,
> Stacy
>
> We are getting ready to set subversion up. We have around 400 GB of
> data currently. I can easily see this data going to about double (800
> GB). What is the max size of a repository?
>
> Thanks,
> Stacy Knutson
I'm not 100% sure but I think it works like this:
If you're using the FSFS backend (which is the default) then the maximum size
of the repository and the maximum size of a revision depend on the filesystem
on which the repository is stored. So you need to find out the maximum size
the filesystem can handle (which would be the maximum size of your
repository) and the maximum size of a single file (which would be the maximum
size for a single commit; mind you, that's not that maximum size of all the
files in that revision, but the maximum size of the *differences*).
So if you run into any limitations here, you "just" need to switch the
filesystem.
Bye,
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Straße 7
D-80686 München
Tel: +49 (0)89 - 548 433 321
e-mail: haisenko@comdasys.com
http://www.comdasys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: How large can a subversion repository be?
Posted by KNUTSON Stacy <St...@3ds.com>.
The data we have is primarily tests for our products. We only change
about 50 files per day across 8 different developer locations. From the
information I found on subversion, it is supposed to handle many small
files without any problems especially with the remote sites. I was
thinking that we would need to connect multiple repositories to get all
the needed data.
Thanks,
Stacy
-----Original Message-----
From: Toby Thain [mailto:toby@smartgames.ca]
Sent: Tuesday, August 28, 2007 10:25 AM
To: KNUTSON Stacy
Cc: users@subversion.tigris.org
Subject: Re: How large can a subversion repository be?
On 28-Aug-07, at 12:33 PM, KNUTSON Stacy wrote:
>
>
> Thanks,
> Stacy
>
> We are getting ready to set subversion up. We have around 400 GB of
> data currently. I can easily see this data going to about double (800
> GB). What is the max size of a repository?
Are you sure you have the right screwdriver for this walnut?
--Toby
>
> Thanks,
> Stacy Knutson
>
> ---------------------------------------------------------------------
> 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: How large can a subversion repository be?
Posted by Toby Thain <to...@smartgames.ca>.
On 28-Aug-07, at 12:33 PM, KNUTSON Stacy wrote:
>
>
> Thanks,
> Stacy
>
> We are getting ready to set subversion up. We have around 400 GB of
> data currently. I can easily see this data going to about double (800
> GB). What is the max size of a repository?
Are you sure you have the right screwdriver for this walnut?
--Toby
>
> Thanks,
> Stacy Knutson
>
> ---------------------------------------------------------------------
> 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
How large can a subversion repository be?
Posted by KNUTSON Stacy <St...@3ds.com>.
Thanks,
Stacy
We are getting ready to set subversion up. We have around 400 GB of
data currently. I can easily see this data going to about double (800
GB). What is the max size of a repository?
Thanks,
Stacy Knutson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Similating "label" feature in Subversion?
Posted by Jean-Claude Antonio <jc...@arcetis.com>.
There are 2 ways you can achieve this.
With Branches
projects
/trunk
/branches
/2007-05-01; Mini-effort on feature A
/2007-05-15; Mini-effort on feature B
/tags
You can always determine the branchpoints (the revision of the creation
of you branch) of your branches :
by using svn log --stop-on-copy
so you can use the svn update -r branchpoint
Or if you want you can create Tags.
- Create your branch, then create you tag (make it then RO by a script
or with authorization)
- Start develop in your branch.
Remember that svn copy is cheap.
projects
/trunk
/branches
/Mini-effort on feature A
/Mini-effort on feature B
/tags
/2007-05-01; Mini-effort on feature A - init
/2007-05-04; Mini-effort on feature A - completed
/2007-05-15; Mini-effort on feature B - init
/2007-05-04; Mini-effort on feature B - completed
then use svn co path_to_tag_name to go back to.
Jean-Claude
Bicking, David (HHoldings, IT) a écrit :
>
> Thank you for your reply. What you suggest is to use the revision. However, I am talking about labeling a revision with a human-readable, searchable text fragment. Some SCM tools permit labels on individual files at specific revisions, though these systems usually keep revisions per file, not per repository.
>
> Thus, on mainline, we would be able to get a list of all labels on the XYZ folder (which is a whole application project) that might look like this:
>
> Branch: 2007-05-01; Mini-effort on feature A
> Merge: 2007-05-04; Mini-effort on feature A completed
> Branch: 2007-05-15; Mini-effort on feature B
> Merge: 2007-05-04; Mini-effort on feature B completed
> Rollback Point: 2007-04-04; This is a safe rollback point during development of feature X.
>
> The above is an example in which I can identify a sort of timeline of development. In the last example, I might have placed that there on the project because we're going to try something particularly experimental over a period of days and want to easily see which revision represents the last good place. Of course, branches could be used for that purpose, too. In some other SCM tools, a rollback to a revision or label results in the elimination of all revisions of the flagged files after that point. I realize that is not the case with Subversion.
>
> --
> David
>
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information. If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited. If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
> ---------------------------------------------------------------------
> 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: Re: Similating "label" feature in Subversion?
Posted by Dave Grundgeiger <da...@codenouveau.com>.
David Bicking wrote:
...
> I am talking about labeling a revision with a human-readable,
> searchable text fragment.
...
> Thus, on mainline, we would be able to get a list of all labels on the
> XYZ folder (which is a whole application project) that might look like
> this:
>
> Branch: 2007-05-01; Mini-effort on feature A
> Merge: 2007-05-04; Mini-effort on feature A completed
> Branch: 2007-05-15; Mini-effort on feature B
> Merge: 2007-05-04; Mini-effort on feature B completed
> Rollback Point: 2007-04-04; This is a safe rollback point during
> development of feature X.
>
> The above is an example in which I can identify a sort of timeline of
> development. In the last example, I might have placed that there on
> the project because we're going to try something particularly
> experimental over a period of days and want to easily see which
> revision represents the last good place.
Hi David. I think I'm missing something. If you create a tag at each of the
above milestones, giving the tag the desired human-readable name, then your
tags folder contains the list that you show above, and you can revert to any
tag at will. Is there additional behavior that you need?
Dave
-------
Develop .NET Software on Open-Source Tools
http://www.codenouveau.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Similating "label" feature in Subversion?
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Jean-Claude Antonio [mailto:jcantonio@arcetis.com]
> Sent: Sunday, August 26, 2007 9:38 AM
> To: fj
> Cc: users@subversion.tigris.org
> Subject: Re: Similating "label" feature in Subversion?
>
> Hello David,
>
> I am not sure I understand this specific issue, as you can
> always get the specific "label" (r31).
> Would svn export|co -r31 ... solve the problem?
> Also in svn tags should not be modified as opposed to
> branches (you can write scripts if needed).
> Cheers,
>
> *Jean-Claude Antonio*
> Responsable Méthodes/Outils
> Arcetis,
> VoilaSVN Subversion Search Engine
> Tél: +33 (0)6 09 13 15 63 - Fax: +33 (0)9 59 18 24 38
> Mél: jcantonio@arcetis.com
> www.arcetis.com
>
>
>
> fj a écrit :
> >
> > Bicking, David (HHoldings, IT) wrote:
> >> I have an interesting situation where labels (rather than "tags")
> >> would be handy. I want to identify a certain revision (r31) as a
> >> suitable rollback point during testing. Since we're testing the
> >> functionality of Subversion, we don't really care about
> the revisions
> >> after this stable starting point. We care about whether
> the behavior
> >> is as expected, and we might want to rollback all changes
> to r31 to start fresh.
> >>
> >> Now, this is just the current need. I can forsee where we
> might want
> >> to identify particular revisions for the future. For example "We
> >> created branch XYZ at this revision". Of course, these
> labels would
> >> have to be something we can easilly see with a report or
> by looking
> >> at a property history on the repository.
> >>
> >> Do any of you know an efficient way to get this functionality? I
> >> took a quick stab at creating a custom property called
> "label" but it
> >> doesn't seem to be what I need. When I update it, the original is
> >> then hidden in history and I can't really find it in a repository
> >> browser or a property list in my workspace.
> >>
> >>
> >> --
> >> David Bicking
> >>
> >>
> >>
> *********************************************************************
> >> ****
> >>
> >> This communication, including attachments, is for the
> exclusive use
> >> of addressee and may contain proprietary, confidential and/or
> >> privileged information. If you are not the intended
> recipient, any
> >> use, copying, disclosure, dissemination or distribution is
> strictly
> >> prohibited. If you are not the intended recipient, please
> notify the
> >> sender immediately by return e-mail, delete this communication and
> >> destroy all copies.
> >>
> *********************************************************************
> >> ****
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: users-help@subversion.tigris.org
> >>
> >>
> > for what it's worth, I second the idea (as i have in previous
> > messages) of implementing a real label feature in svn.
> >
> > I was a StarTeam administrator for 6 years, as well as being the qa
> > director, primary software config. mgmt. authority, and I
> think I also
> > washed a few bottles every now and then at that same gig. With
> > StarTeam, we used their view-level and rev-level labeling feature
> > extensively; it is quite powerful. I don't want to run-on about it,
> > but if anybody has any questions about it I'll certainly try to
> > elaborate. My point is, labeling, done well, can indeed be a very
> > useful capability.
> >
> > Don't get me wrong -- SVN's a great tool, especially for the price
> > (StarTeam cost a stunningly large amount of money for the number of
> > licenses the organization owned), and I'm generally agnostic about
> > tools -- use what I have to, use what I've got, etc., and
> figure out
> > how to make it work. Part of the ex-military in me... but
> I do miss
> > some of StarTeam's features, and a true labeling capability like
> > StarTeam has is one of those features I miss.
> >
> > cheers,
> > fj
> >
Thank you for your reply. What you suggest is to use the revision. However, I am talking about labeling a revision with a human-readable, searchable text fragment. Some SCM tools permit labels on individual files at specific revisions, though these systems usually keep revisions per file, not per repository.
Thus, on mainline, we would be able to get a list of all labels on the XYZ folder (which is a whole application project) that might look like this:
Branch: 2007-05-01; Mini-effort on feature A
Merge: 2007-05-04; Mini-effort on feature A completed
Branch: 2007-05-15; Mini-effort on feature B
Merge: 2007-05-04; Mini-effort on feature B completed
Rollback Point: 2007-04-04; This is a safe rollback point during development of feature X.
The above is an example in which I can identify a sort of timeline of development. In the last example, I might have placed that there on the project because we're going to try something particularly experimental over a period of days and want to easily see which revision represents the last good place. Of course, branches could be used for that purpose, too. In some other SCM tools, a rollback to a revision or label results in the elimination of all revisions of the flagged files after that point. I realize that is not the case with Subversion.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Similating "label" feature in Subversion?
Posted by Jean-Claude Antonio <jc...@arcetis.com>.
Hello David,
I am not sure I understand this specific issue, as you can always get
the specific "label" (r31).
Would svn export|co -r31 ... solve the problem?
Also in svn tags should not be modified as opposed to branches (you can
write scripts if needed).
Cheers,
*Jean-Claude Antonio*
Responsable Méthodes/Outils
Arcetis,
VoilaSVN Subversion Search Engine
Tél: +33 (0)6 09 13 15 63 - Fax: +33 (0)9 59 18 24 38
Mél: jcantonio@arcetis.com
www.arcetis.com
fj a écrit :
>
> Bicking, David (HHoldings, IT) wrote:
>> I have an interesting situation where labels (rather than "tags") would
>> be handy. I want to identify a certain revision (r31) as a suitable
>> rollback point during testing. Since we're testing the functionality of
>> Subversion, we don't really care about the revisions after this stable
>> starting point. We care about whether the behavior is as expected, and
>> we might want to rollback all changes to r31 to start fresh.
>>
>> Now, this is just the current need. I can forsee where we might want to
>> identify particular revisions for the future. For example "We created
>> branch XYZ at this revision". Of course, these labels would have to be
>> something we can easilly see with a report or by looking at a property
>> history on the repository.
>>
>> Do any of you know an efficient way to get this functionality? I took a
>> quick stab at creating a custom property called "label" but it doesn't
>> seem to be what I need. When I update it, the original is then hidden
>> in history and I can't really find it in a repository browser or a
>> property list in my workspace.
>>
>>
>> --
>> David Bicking
>>
>>
>> *************************************************************************
>>
>> This communication, including attachments, is
>> for the exclusive use of addressee and may contain proprietary,
>> confidential and/or privileged information. If you are not the intended
>> recipient, any use, copying, disclosure, dissemination or
>> distribution is
>> strictly prohibited. If you are not the intended recipient, please
>> notify
>> the sender immediately by return e-mail, delete this communication and
>> destroy all copies.
>> *************************************************************************
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
> for what it's worth, I second the idea (as i have in previous
> messages) of implementing a real label feature in svn.
>
> I was a StarTeam administrator for 6 years, as well as being the qa
> director, primary software config. mgmt. authority, and I think I also
> washed a few bottles every now and then at that same gig. With
> StarTeam, we used their view-level and rev-level labeling feature
> extensively; it is quite powerful. I don't want to run-on about it,
> but if anybody has any questions about it I'll certainly try to
> elaborate. My point is, labeling, done well, can indeed be a very
> useful capability.
>
> Don't get me wrong -- SVN's a great tool, especially for the price
> (StarTeam cost a stunningly large amount of money for the number of
> licenses the organization owned), and I'm generally agnostic about
> tools -- use what I have to, use what I've got, etc., and figure out
> how to make it work. Part of the ex-military in me... but I do miss
> some of StarTeam's features, and a true labeling capability like
> StarTeam has is one of those features I miss.
>
> cheers,
> fj
>
> ---------------------------------------------------------------------
> 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: Similating "label" feature in Subversion?
Posted by fj <fj...@effjay.com>.
Bicking, David (HHoldings, IT) wrote:
> I have an interesting situation where labels (rather than "tags") would
> be handy. I want to identify a certain revision (r31) as a suitable
> rollback point during testing. Since we're testing the functionality of
> Subversion, we don't really care about the revisions after this stable
> starting point. We care about whether the behavior is as expected, and
> we might want to rollback all changes to r31 to start fresh.
>
> Now, this is just the current need. I can forsee where we might want to
> identify particular revisions for the future. For example "We created
> branch XYZ at this revision". Of course, these labels would have to be
> something we can easilly see with a report or by looking at a property
> history on the repository.
>
> Do any of you know an efficient way to get this functionality? I took a
> quick stab at creating a custom property called "label" but it doesn't
> seem to be what I need. When I update it, the original is then hidden
> in history and I can't really find it in a repository browser or a
> property list in my workspace.
>
>
> --
> David Bicking
>
>
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information. If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited. If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
for what it's worth, I second the idea (as i have in previous messages)
of implementing a real label feature in svn.
I was a StarTeam administrator for 6 years, as well as being the qa
director, primary software config. mgmt. authority, and I think I also
washed a few bottles every now and then at that same gig. With
StarTeam, we used their view-level and rev-level labeling feature
extensively; it is quite powerful. I don't want to run-on about it, but
if anybody has any questions about it I'll certainly try to elaborate.
My point is, labeling, done well, can indeed be a very useful capability.
Don't get me wrong -- SVN's a great tool, especially for the price
(StarTeam cost a stunningly large amount of money for the number of
licenses the organization owned), and I'm generally agnostic about tools
-- use what I have to, use what I've got, etc., and figure out how to
make it work. Part of the ex-military in me... but I do miss some of
StarTeam's features, and a true labeling capability like StarTeam has is
one of those features I miss.
cheers,
fj
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org