On Wed, 2006-11-29 at 12:04 -0800, L. Wayne Johnson wrote:
>
> >> 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.
The problem comes when you want both a frozen snapshot of your workspace
_and_ your changes committed to the head of a trunk/branch where others
may be working. There is nothing to tie these together. When you look
at the trunk version you can't see anything to show when the tag copy
was made. When you look at the tag, you might find something that isn't
even committed to the trunk since nothing forces you to commit there as
well.
> 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.
That would depend on how you do it.
> >>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.
Exactly, and what I'm thinking about is that I don't want to force
everyone else to stop working or to be unable to update to each
other's changes easily just because I need to make a few changes
to an otherwise frozen snapshot.
> 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.
How do you pick up other people's changes when you want them?
> 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.
Suppose you also have to roll out a release of what you have while
others are making changes that will go in the next release, and it's on
a fast schedule - you might be doing it again tomorrow. You want to
tag every release so you can easily back out to an earlier one and
you want the changes you make to be included when you pick up the
concurrent work on the trunk for the next round. Is it worth all the
branching and merging just to identify the mixed revision in your
working copy now?
> 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.
The subversion manual shows an understanding that workspaces often need
to hold mixed revisions. For the same reasons, you will often need
to be able to reproduce that workspace and the only mechanism that
subversion provides is a copy to a new tag or branch, neither of
which meshes well with ongoing concurrent work. If someone else has
committed changes you don't want to include at the time you commit,
you cannot make a trunk or existing branch revision match what you
have in your working copy.
> 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.'
If you have committed all your changes, everything is in fact in the
repository, but no "repository revision" matches the state you want
if unwanted commits happened first.
> Subversion currently let you decide where that copy will be created by
> leaving it up to you to make it.
Copying workspace to tag is OK, but now how do you (a) know that
everything in the tag really was committed to the trunk and (b)
if it was, find out when by looking at the copy in the trunk?
And the other missing piece is the ability to float a tag from
one place to another so you can reuse known names. I think someone
mentioned a utility that might do this, so perhaps the underlying
mechanism is available.
> 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.
The thing is that the files do have version numbers that you can see
with 'svn info'. The functionality I'm describing could be managed
with a file containing the 'info' data on the files in the workspace
you wanted to tag (making sure that everything has been committed...)
and using that to check them out or update to those revisions again.
And of course such a file could itself be versioned to satisfy those
people who say that changing labels alters history.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 22:07:45 2006