On Wed, Nov 22, 2006 at 05:22:45PM +0100, Felix Gilcher wrote:
> John Rouillard <mailto:rouilj@renesys.com> schrieb am Mittwoch, 22. November 2006 16:53:
>
> > On Wed, Nov 22, 2006 at 09:49:01AM +0100, Robert Graf-Waczenski wrote:
> >>> 2. How many labels can be attached to a revision? One? Any number?
> >>
> >> Only one. (Remember, we're talking *poor* man's labels here...)
> >
> > So adding a new label to the rev destroys the old label? I think this
> > is wrong. Any given revision should be able to have the same label.
> > Especially with mutable labels you may need to double label a revision
> > with a permanent label (say PRODUCTION_2006_11_22) and a floating
> > lable (CURRENT_PRODUCTION).
>
> I see you're trying to replace tags by labels. You really should be
> aware that if a label is a revision alias it does not carry enough
> information to identify a production release. Regard subversion as a
> versioned filesystem. Every resource can be identified by 2
> coordinates: a paths and a time coordinate.
With you so far. I think I am the one who made the original argument
on tags being really revisions and therefore are time based but that
svn represents (confusingly) in path space.
> Time is what you specify
> with the revision argument to the svn command unless HEAD is
> implied. So what does a label "PRODUCTION" mean if it references
> revision X?
"revision X" of a file. Not of the repository. I think this may have
diverged a bit. Is your PMT a symbolic name for -r 121 of every file
in the repository, or is it a symbolic name that can be applied to
individual files/paths in the repository?
>Is it
>
> componentY/stable/version1/ at revision X
>
> or maybe
>
> componentY/development/currently_broken/ at revision X
It can be either same as a tag can represent either. It's just a name
for a file at a particular version of the repository.
Much the same as -r 121 can be broken for some path in the repository
and working for some other path.
> Things get even worse when you have a repository as the apache
> foundation [1] has: all ASF projects from ANT to xmlgraphics are in
> a single repository - this is quite a common usecase. What does the
> label "PRODUCTION" mean in this context?
What does any label mean then? If the label is repository revision
wide, then ant at "Rel 1.0" of the repository may be totally broken
since "Rel 1.0" was meant to be release 1.0 of xmlgraphics which does
work.
> So you'd have to specify
>
> svn co -r"APR_PRODUCTION" http://svn.apache.org/repos/asf/apr/apr/trunk/
>
> or something similar instead of
>
> svn co http://svn.apache.org/repos/asf/apr/apr/tags/1.2.7/
>
> Which one of the two is more error prone?
Neither, either. Depends on what you are used to. I would think the
first would map to most people's way of thinking better. I want these
files at this time. Not those other files. I do agree that the tags
being mapped to a pure URL is easier to transport and link to however,
but we could also do:
http://svn.apache.org/repos/asf/apr/apr/trunk/#APR_PRODUCTION
and define that convention to get the same ease.
> Without a doubt the first
> one. What happens if you confuse which labels belong to which path
> of your project? You may get build errors or even worse build and
> release old, buggy versions. The current tagging mechanism is way
> more suited to identifying frozen revisions such as "PRODUCTION".
What you are assuming is that there is a simple way to create the tag
and in a mixed revision "releases" there may not be. If I have 100
files from 10 different revisions I need an easy way to label those
files at a given revision. Copying them all to path space in a working
copy is a major pain. Labels (as I think you said) can be applied to
any revision anywhere in the path space.
I've been there, it's a major hassle that doesn't exist with CVS and
the ability to retag (re-label) files.
What I want is an easy way to stay inthe time dimention and group
revisions in the time dimention.
See the last graphic in:
http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_4.html#SEC48
I want that arrow linking the files. The only difference would be that
the revision numbers are not per file but per repository. So rather
than 1.2 think 12.
I could use branches/tags but the major overhead of switching,
updating and trying to keeping them up to date is a nightmare. Plus I
lose the history info for the file that has occurred since the
branch. I get the prior info but if I want to see what has changed in
themainline version of the file, I cn't do that by looking at the
branch. I have to manually:
identify the trunk revision where the tagged copy came off the
trunk
locate the trunk copy's path and svn log it.
I can't just svn log the trunk copy and scan back to the location
where the label was set, or even:
svn log -r LABEL:HEAD trunk/file
so the log info stops at the LABEL (I think I got the syntax right but
I hope you get the idea).
Now I ask you which is more error prone?
Basically copying the file breaks the timeline in major ways and I am
trying to get some way of maintaining the timeline and being able to
identify particular revisions of files that can be checked
out/diffed/updated to etc. as a unit.
> Make it possible to specify a svn url in the -r argument. If the
> argument is an url, it gets replaced by the revision in which the
> branch/tag was created. There are some corner cases (what happens if
> the url does not point to branch etc.), but it would be possible to
> create such an implementation as a shellwrapper to svn for testing
> purposes.
That doesn't address the difficulty in creating the tag in the first
place.
--
-- 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
Received on Wed Nov 22 18:09:13 2006