>> -----Original Message-----
>> From: Les Mikesell [mailto:lesmikesell@gmail.com]
>> Sent: Wednesday, November 29, 2006 6:05 AM
>> To: Gerco Ballintijn
>> Cc: 'Subversion Users'
>> Subject: Re: Simple Label=RevisionID Discussion
>>
>> On Wed, 2006-11-29 at 05:30, Gerco Ballintijn wrote:
>>
>> > The other problem with revision properties, as indicated by Tim Hill,
>> > is that they cannot be set at revision creation time. Solving this
>> > problem would make them significantly easier to use, and thus more
>> > useful.
>>
>> Is it possible to set them on only the revisions that exist
>> in your workspace as you commit? As I've mentioned a few
>> times before, it is a common problem that you want to
>> tag an exact match to your workspace, including changes
>> you've committed, but _not_ include revisions committed
>> to the repository by others that you haven't updated to
>> in your working copy.
You cannot simply 'tag' a mixed revision. As you noted it does not exist in
the repository. Sure code could be added that would allow you to create some
new type of entity but why? It is already possible to create a copy which is
fast and takes up little room. I haven't looked at the svn code but I do
browse the developer forum and from what I understand it would be very slow
to do what you ask.
>>CVS lets you do this and it is
>> often necessary for concurrent development work. >>Subversion
>> mentions the situation in the manual but provides no way
>> to deal with it in the repository. You can copy the workspace
>> to a tag which won't match any revision state of the trunk
>> or branches, but you are on your own to commit separately
>> to wherever else the ongoing work belongs - and then there
>> is nothing to associate those commits with the separate
>> tag copy.
CVS versions files and not files systems. This is a completely different
paradigm. You must also shift your own thinking. Instead of worrying about
specific files think about the whole project in general. In the end this is
what you really care about. For example, I have my own individual area in
the repository. I create a branch when I start working on something (other
than truly trivial changes.) I make changes and check stuff in very
frequently. If I screw something up I can go back easily. I don't have to
keep a bunch of copies of files with intermediate changes in them. Then once
I have completed my work I merge it into the main development tree wherever
it belongs.
There are some quirks to the process related mainly related to revision
tracking and merging. But this is where the current development is focused.
I believe that once these issues are addressed it will be possible to solve
the underlying needs without adding the per file versioning which is what
this thread really seems to be asking for.
If a different mechanism is going to be added,
>> it should be something that can handle these needed
>> mixed-revision states.
No matter what that mechanism is, it will require making a copy of your
mixed revision. If a copy is not made then there isn't anything to 'tag.'
Subversion currently let you decide where that copy will be created by
leaving it up to you to make it. The only other option is to create (or
simulate) per file versioning. Without a lot of work this is likely to be a
slow operation since you would have to search every file in the repository
for a specific version. Trivial (read here: ones that require the least
amount of work) implementations are going to be exponential in running time.
Probably for both the number of files and the number of revisions that
exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 21:06:06 2006