You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Kramer <da...@thekramers.net> on 2004/12/29 19:18:27 UTC
Labeling revisions advice sought
In my company, we're switching from PVCS to Subversion. I'm the
evangelist and implementer of the change (in other words, I HAVE to
practice what I preach).
In addition to the normal releases, which we will use "svn copy" to track,
when we are coming up on a release, we also do "letter builds" on a daily
basis. If we're coming up on release 8.0, before it's released, we will
do 8.0a, 8.0b, ... 8.0z, 8.0aa, 8.0ab, etc until the actual release.
Currently we have the ability to associate revisions of files with labels
in PVCS, so before doing build 8.0ce, the head revision of each file gets
a label like REV8.0ce.
In a perfect world, the developers would be able to do something like they
do now with PVCS, using labels interchangably with version numbers:
svn checkout -r 8.0aa $SVNREPOS/trunk/mymodule
I'm trying to figure out how to do that in subversion. The obstacles I
see are:
- I don't want to do an svn copy every day for one of these builds,
because I think that would make the repository huge. I know it's a
"cheap" copy, but cheap != free, and 50 or 60 cheap copies of thousands of
files for every release can add up. I expect it would slow down access
after a while, too.
- I played with the idea of having a special file in the repository that
gets revision/label property pairs assigned to it, but apparently you
cannot get the properties of a file by URL, only working copy. Even if
that worked, though, that helps me store the association, but I still need
a script to get the value out, and the user needs to retype it on the svn
co line.
- Revision properties do the reverse of what I want. I want the revision
that contains a certain property (or a particular value for a particular
property), not the value of a property for a perticular revision.
The best compromise I came up with so far is:
-I have a file revlabels.txt that stores the associations in the form
rev release
This file is in Subversion.
-I wrote a script that is beautiful in it's hackishness. The heart of
getrevlabel.sh is:
svn cat $SVNREPOS/build/revlabels.txt | \
awk -v LABEL="$1" '$1==LABEL {print $2}'`
Now the user can svn checkout -r `getrevlabel.sh 8.0a` $SVNREPOS
Frankly, my boss is staring at me dumbfounded how svn doesn't support some
kind of labels like this. I hope I'm missing something. How does
everyone else associate a particular build with a revision number?
Thanks in advance.
--
DDDD
DK KD Those who do not reason are bigots.
DKK D Those who cannot, are fools.
DK KD Those who will not, are slaves.
DDDD - Lord Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by David Kramer <da...@thekramers.net>.
On Wed, 29 Dec 2004, Garrett Rooney wrote:
> David Kramer wrote:
> >>That's not really true. When you make a copy of a large directory
> >>containing hundreds of files you're really not copying all the files.
> >>The number of files copied is not meaningful at all in determining how
> >>much space will be used in the repository, it's a constant amount for
> >>each copy, no matter how many files are involved.
> >
> > One of the things the book says you can do (in "Creating a complex
> > tag") is assemble a working copy that has mixed revisions (different
> > files at different revisions in the same working copy), and do an svn
> > copy of the working copy. If the repository doesn't have a record for
> > every single file in the new copy, how can it handle this scenario?
>
> Ok, you didn't say you were creating mixed revision copies. In that
> case it's a bit more complex. Let me try to explain.
>
> You need to realize that directories in the Subversion filesystem are
> basically collections of pointers to other entries in the filesystem
> (either files or other directories), and can refer to previous version
> of existing entities. So I can have something where /tags/0.1.0/foo
> really refers to revision 10 of /trunk/foo, even though at the time we
> created /tags/0.1.0 /trunk/foo was really at revision 15.
>
> To do this, there is some small additional cost as compared to a simple
> copy of /trunk to /tags/0.1.0. Normally, if I copy /trunk to /tags/blah
> then I need to create a new directory entry for /tags (which holds the
> new 'blah' entry in addition to whatever was there) and a new directory
> entry for / (which holds tags, trunk, and branches probably). If this
> was further down in the repository there would be other directories
> created as well, bubbling up from the copy all the way to the root.
>
> If you make a mixed-revision copy, all that same stuff gets copied, plus
> new directory entries need to be created for each subdirectory in the
> tree that contains mixed revisions. So if I want /tags/0.1.0/foo to be
> different from what exists in /trunk/foo when I make the copy I'll add
> one more directory entry, for /tags/0.1.0, which will have to record the
> fact that it's 'foo' entry points to /trunk/foo from that earlier
> revision.
>
> So the total cost is proportional to the number of directories that
> contain differences, relative to it's parent directory.
I understand about 92% of what you wrote, but if your last paragraph is
true, then I simply won't worry about it. Thanks for your advice.
----------------------------------------------------------------------------
DDDD David Kramer david@thekramers.net http://thekramers.net
DK KD
DKK D Live long and prosper. - Vulcan proverb
DK KD And eat well. - Jewish addendum to Vulcan proverb
DDDD Feast on your enemies! - Klingon interpertation of Jewish addendum
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
David Kramer wrote:
> On Wed, 29 Dec 2004, Garrett Rooney wrote:
>
>
>>David Kramer wrote:
>>
>>
>>>I'm trying to figure out how to do that in subversion. The obstacles I
>>>see are:
>>>
>>>- I don't want to do an svn copy every day for one of these builds,
>>>because I think that would make the repository huge. I know it's a
>>>"cheap" copy, but cheap != free, and 50 or 60 cheap copies of thousands of
>>>files for every release can add up. I expect it would slow down access
>>>after a while, too.
>>
>>That's not really true. When you make a copy of a large directory
>>containing hundreds of files you're really not copying all the files.
>>The number of files copied is not meaningful at all in determining how
>>much space will be used in the repository, it's a constant amount for
>>each copy, no matter how many files are involved.
>
>
> One of the things the book says you can do (in "Creating a complex tag")
> is assemble a working copy that has mixed revisions (different files at
> different revisions in the same working copy), and do an svn copy of the
> working copy. If the repository doesn't have a record for every single
> file in the new copy, how can it handle this scenario?
Ok, you didn't say you were creating mixed revision copies. In that
case it's a bit more complex. Let me try to explain.
You need to realize that directories in the Subversion filesystem are
basically collections of pointers to other entries in the filesystem
(either files or other directories), and can refer to previous version
of existing entities. So I can have something where /tags/0.1.0/foo
really refers to revision 10 of /trunk/foo, even though at the time we
created /tags/0.1.0 /trunk/foo was really at revision 15.
To do this, there is some small additional cost as compared to a simple
copy of /trunk to /tags/0.1.0. Normally, if I copy /trunk to /tags/blah
then I need to create a new directory entry for /tags (which holds the
new 'blah' entry in addition to whatever was there) and a new directory
entry for / (which holds tags, trunk, and branches probably). If this
was further down in the repository there would be other directories
created as well, bubbling up from the copy all the way to the root.
If you make a mixed-revision copy, all that same stuff gets copied, plus
new directory entries need to be created for each subdirectory in the
tree that contains mixed revisions. So if I want /tags/0.1.0/foo to be
different from what exists in /trunk/foo when I make the copy I'll add
one more directory entry, for /tags/0.1.0, which will have to record the
fact that it's 'foo' entry points to /trunk/foo from that earlier revision.
So the total cost is proportional to the number of directories that
contain differences, relative to it's parent directory.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by Max Bowsher <ma...@ukf.net>.
David Kramer wrote:
> On Wed, 29 Dec 2004, Garrett Rooney wrote:
>
>> David Kramer wrote:
>>
>>> I'm trying to figure out how to do that in subversion. The obstacles I
>>> see are:
>>>
>>> - I don't want to do an svn copy every day for one of these builds,
>>> because I think that would make the repository huge. I know it's a
>>> "cheap" copy, but cheap != free, and 50 or 60 cheap copies of thousands
>>> of
>>> files for every release can add up. I expect it would slow down access
>>> after a while, too.
>>
>> That's not really true. When you make a copy of a large directory
>> containing hundreds of files you're really not copying all the files.
>> The number of files copied is not meaningful at all in determining how
>> much space will be used in the repository, it's a constant amount for
>> each copy, no matter how many files are involved.
>
> One of the things the book says you can do (in "Creating a complex tag")
> is assemble a working copy that has mixed revisions (different files at
> different revisions in the same working copy), and do an svn copy of the
> working copy. If the repository doesn't have a record for every single
> file in the new copy, how can it handle this scenario?
It records each subtree that is different to it's parent.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by David Kramer <da...@thekramers.net>.
On Wed, 29 Dec 2004, Garrett Rooney wrote:
> David Kramer wrote:
>
> > I'm trying to figure out how to do that in subversion. The obstacles I
> > see are:
> >
> > - I don't want to do an svn copy every day for one of these builds,
> > because I think that would make the repository huge. I know it's a
> > "cheap" copy, but cheap != free, and 50 or 60 cheap copies of thousands of
> > files for every release can add up. I expect it would slow down access
> > after a while, too.
>
> That's not really true. When you make a copy of a large directory
> containing hundreds of files you're really not copying all the files.
> The number of files copied is not meaningful at all in determining how
> much space will be used in the repository, it's a constant amount for
> each copy, no matter how many files are involved.
One of the things the book says you can do (in "Creating a complex tag")
is assemble a working copy that has mixed revisions (different files at
different revisions in the same working copy), and do an svn copy of the
working copy. If the repository doesn't have a record for every single
file in the new copy, how can it handle this scenario?
--
DDDD David Kramer david@thekramers.net http://thekramers.net
DK KD
DKK D "Designing pages in HTML is like having sex in a bathtub. If you
DK KD don't know anything about sex, it won't do you any good to know
DDDD a lot about bathtubs" - vagabond@mcgurkus.circus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
David Kramer wrote:
> I'm trying to figure out how to do that in subversion. The obstacles I
> see are:
>
> - I don't want to do an svn copy every day for one of these builds,
> because I think that would make the repository huge. I know it's a
> "cheap" copy, but cheap != free, and 50 or 60 cheap copies of thousands of
> files for every release can add up. I expect it would slow down access
> after a while, too.
That's not really true. When you make a copy of a large directory
containing hundreds of files you're really not copying all the files.
The number of files copied is not meaningful at all in determining how
much space will be used in the repository, it's a constant amount for
each copy, no matter how many files are involved.
> Frankly, my boss is staring at me dumbfounded how svn doesn't support some
> kind of labels like this. I hope I'm missing something. How does
> everyone else associate a particular build with a revision number?
You make a tag, by copying the trunk into your tags directory.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by David Kramer <da...@thekramers.net>.
Christophe Labouisse wrote, On 12/29/2004 04:04 PM:
> On Wed, 29 Dec 2004 14:18:27 -0500 (EST)
> David Kramer <da...@thekramers.net> wrote:
>
>
>>- I don't want to do an svn copy every day for one of these builds,
>>because I think that would make the repository huge. I know it's a
>>"cheap" copy, but cheap != free, and 50 or 60 cheap copies of
>>thousands of files for every release can add up. I expect it would
>>slow down access after a while, too.
>
>
> After reading your mail I made a little test. I took a project
> containing about 21000 files import it into a new SVN repository and
> after that created 50 tags by copying /trunk/project to /labels/xx.
> After importation the repository was 643MB and only 645MB after my 50
> tags. Like all tests, this one is stupid but my guess is that subversion
> tagging by cheap copy is probably as space efficient as the PVCS
> labeling system.
>
Heh. I have essentially the same test planned for one of our engineers to do
this week. I didn't get the size information from him yet, but the
performance test showed a slight, but acceptable slowdown.
Sounds like I was worrying for nothing.
And thanks for running the test for confirmation.
-------------------------------------------------------------------
DDDD David Kramer http://thekramers.net
DK KD
DKK D "The only problem with doing it right the first time is
DK KD that nobody appreciates how difficult it was"
DDDD - Anonymous
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Labeling revisions advice sought
Posted by Christophe Labouisse <ch...@labouisse.org>.
On Wed, 29 Dec 2004 14:18:27 -0500 (EST)
David Kramer <da...@thekramers.net> wrote:
> - I don't want to do an svn copy every day for one of these builds,
> because I think that would make the repository huge. I know it's a
> "cheap" copy, but cheap != free, and 50 or 60 cheap copies of
> thousands of files for every release can add up. I expect it would
> slow down access after a while, too.
After reading your mail I made a little test. I took a project
containing about 21000 files import it into a new SVN repository and
after that created 50 tags by copying /trunk/project to /labels/xx.
After importation the repository was 643MB and only 645MB after my 50
tags. Like all tests, this one is stupid but my guess is that subversion
tagging by cheap copy is probably as space efficient as the PVCS
labeling system.
--
Le cinéma en Lumière : http://www.lumiere.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Labeling revisions advice sought
Posted by Dale Worley <dw...@pingtel.com>.
-----Original Message-----
From: David Kramer [mailto:david@thekramers.net]
- I don't want to do an svn copy every day for one of these builds,
because I think that would make the repository huge. I know it's a
"cheap" copy, but cheap != free, and 50 or 60 cheap copies of thousands of
files for every release can add up.
--------------------------
Well, I'd expect the cost of a copy to be several tens of bytes.
Multiplying 20 bytes/copy * 60 copies/file * 10,000 files = 12 megabytes,
which doesn't seem to be much these days. (And most of the files do not
need to be mentioned individually, as other posters have noted.)
--------------------------
I expect it would slow down access after a while, too.
--------------------------
I would hope not. Well-designed data structures usually have access time
proportional to at most the log of the number of items in the data
structure, so you might be adding 50% to the file-lookup time, not 50 times.
--------------------------
- I played with the idea of having a special file in the repository that
gets revision/label property pairs assigned to it, but apparently you
cannot get the properties of a file by URL, only working copy.
--------------------------
"svn propget svn:externals https://scm.sipfoundry.org/rep/sipXpbx/main"
worked for me.
-----------------
-I wrote a script that is beautiful in [its] hackishness. The heart of
getrevlabel.sh is:
svn cat $SVNREPOS/build/revlabels.txt | \
awk -v LABEL="$1" '$1==LABEL {print $2}'
Now the user can svn checkout -r `getrevlabel.sh 8.0a` $SVNREPOS
-----------------
function svn-checkout-label()
{
svn checkout -r $( svn cat $SVNREPOS/build/revlabels.txt | \
awk '$1=="'$1"' {print $2}' $) $SVNREPOS
}
The user can do "svn-checkout-label 8.0a".
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org