Saulius Grazulis wrote:
>AFAIU, repo can not be in a "mixed-revision" state. I records sequential
>revisions, one after another. Only WC can be constructed to be in a
>"mixed-revision", that is to contain objects at different revisions.
>
>
This is an ambiguity about the word "revision". A Repository can have
multiple points in it which are different "revisions" (in a different
state, despite being logically, according to each user, the same file.
Eg: foo.c in branches/varen-dev and foo.c in branches/shruggar-dev might
"logically" be the same file, but from one point to the next there is no
garantee that they are similar. That is, one could be synchronized with
trunk, the other might have some test fixes and not actually build), but
the repository itself has a global "revision number" which can be used
in combination with a path to refer to a file at a given point in time.
Assume /tags/FOO was created in revision 333. Saying "FOO means 333"
would be in error because -r333 /trunk/bar.c is not neccessarily equal
to /tags/FOO/bar.c, or even relevent, while -r333 /branches/steve/bar.c
would certainly be utterly irrelevent. Others in this thread have stated
this much better than I.
Due to this fact by itself, giving the user implication that revision
numbers can be completely detached from paths and still have meaning is
a mistake.
Yes, Subversion requires more typing than an implementation which allows
revision numbers to be aliased, but this is all intentional in order to
avoid ambiguity. While I would love for any feature which kept SVN's
current model _and_ cut down on typing, this would not be one of them:
it would add no functionality which SVN does not already have, yet would
not use that existing functionality.
No tool should prevent you from doing something it thinks is a mistake,
but it shouldnt add a whole new re-implementation of an existing feature
just to make that mistake possible.
Please correct this if I miss anything. This feature would intend to fix
the defficiencies of:
- Lots of extra typing
- Lack of a way to warn if you try to check-in something you only meant
to merge temporarily
- Lack of an easy (read: short to type, "not having to remember a lot")
way to reverse a temporary merge
- Lack of a built-in way to mark something as "read only"
- Lack of a way to quickly refer to something you forgot to include in
a tag
Notes on the last two, kept seperate because I want to keep the list
itself free of opinions:
- re: "read only": I think this one is more related to built-in ACLs,
which I hear no one is working on.
- re: "forgot to tag": I don't think any sensible system should try to
help out with "I forgot to include this part". You can always use the
log to find the revnum if you just copied one-branch-too-deep, and
presumably you'd then correct the mistake right there.
_please_ let's discuss ways to work on these (and others, if you care to
add) percieved deficiencies of the current system, rather than running
in the same circle of people who completely reject the current system vs
people who think it's just fine. Let's accept that we currently have
this particular system of doing things, and it's not going to be
re-invented. But if you want to talk about its current problems, I'm
fine with that. I think a lot of this flame war is just a result of
people not understanding what the other side is talking about regarding
the current problems and current solutions and why they are inadequate.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 28 14:25:08 2006