just to put one thing straight: I'm not the one who brought up the idea of "labels as revision alias". I'm not opposed per se, but I don't think I need it (and haven't seen a usecase for it so far). I'm just throwing in problems I see with the suggestions made.
John Rouillard <mailto:rouilj@renesys.com> schrieb am Mittwoch, 22. November 2006 18:08:
> 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.
>
IMHO, tags are no time alias. Tags are in themselves a combination of space and time (they can be traced back to a specific revision of a set of specific paths). This is why they need to be immutable. Their representation is secondary and I have no conceptual problem with placing them in the path space. It's just like I could do a photocopy of a letter I'm handwriting and put it in a folder on my shelf. It would be a "time snapshot" of a "3d Space Item" represented by a "3d Space Item" that is immutable over time.
>> 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?
>
To quote the original poster: "A PML can be attached to any existing revision, similar to
revision properties." I'd read it as "label X maps to revision Y for the whole repository" - a mnemonic alias for a given repository revision number.
>> 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.
as quoted: It's a revision number - not a name for a file at a revision.
>
> 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.
so you're mapping the whole time component back into path space for ease. Why that - you can have this right now.
>
>> 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.
>
So what you need might be just a convinient UI to do this:
svn copy -r X proto://repo/trunk/path/to/file1 proto://repo/tags/mytag/path/to/file1
svn copy -r Y proto://repo/trunk/path/to/file2 proto://repo/tags/mytag/path/to/file2
svn copy -r X proto://repo/trunk/path/to/folder1 proto://repo/tags/mytag/path/to/folder1
There is no enforced requirement that a tag must be created in a single operation - it would be nice, but it doesn't have to be this way. Important is that once created it's immutable.
I might be wrong here (it's a long time since I used CVS):
In CVS you'd have to tag each file manually as well unless you tag a working copy. How did you get your working copy in CVS in the first place? By pulling the proper revisions, same as now.
> 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.
If you have a tag you can pull all those files. Just specify the tag as source.
>
> 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
That's what I'm trying to point at: Why not create a wrapper-script for svn that allows this syntax:
svn log -r"path/to/tag/one:HEAD" trunk/file
The wrapper looks up the url, parses the log, calls the "real" svn with the proper arguments and you're done. No need for a secondary mechanism, everything solved with existant tools.
>
> so the log info stops at the LABEL (I think I got the syntax right
> but I hope you get the idea).
>
I agree with you that the current workflow is akward sometimes, but noone forces you to do everything manually. I don't agree with the notion that labels are the magic silver bullet solving this problem.
> Now I ask you which is more error prone?
Everything by hand. But as above: Your computer is expert at solving stupid repetitive tasks. Make him your slave and helper.
>
> 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.
Tortoise allows you to build a revision graph. The information is available, it just that noone built a utility to display it. Retrieving this information is a bit slow at the moment, however solving this is a completely different problem and I don't think that anyone would be opposed to a good solution.
>
>> 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.
How about trying to build a more convinient tool that does this for you? Maybe a script that accepts multiple files as input and calls the proper commands in the background? something like:
svntag path/to/file/one#rev1 path/to/file/2#rev3 /path/to/folder/one#HEAD /path/to/tag/mytag
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
Received on Wed Nov 22 19:18:53 2006