Hello kfogel,
Few comments about your comments:
1. TAGS AND BRANCHES
Again, tags and branches replaced in SVN with copy in repository.
This is similar like all (I think) backup their code before they know
about SCM. For example, I, when was a student, just copy each day
entire source tree of my diploma. You make the same but in repository.
With your approach there NO difference between TAG and BRANCH. All
that is the COPY. One copy, called TAG we _promise_ do not change. And
that's why it is a TAG. But nothing can prevent me from modifying this
COPY. So, some "bad" developer CAN change the TAG. How this looks for
you? That's why we claim that you system not have the TAGS.
Just for me, TAG, is only TAG - some symbolic label that describes
_some_ state of source code (entire rep, or some of its folder, or
some file). In SVN such state is _repository revision_. That's why I
make analog between TAG and your REP REVISION.
And finally, if you will allow to "mark" or "associate" some
symbolic name with your REVISION for me it will be the TAG. In other
words I only just one mark r12345 as "rev_1_1".
Why this needed? Very simple. I just want to get difference between
my current version and version 1.0 (for example). Right now I need to
compare file "_svnserver/tags/version1_0/myfile.c" with
"_svnserver/myfile.c" or "r12000" with "r12356". The first is very
complex (why to type full path, only because I not remember revision
of version1-0). Other (user revision) is simple, but I NOT remember
numeric revision of "version1_0". That's why, I think, symbolic labels
for numeric revisions (TAGS are needed).
2. No comment about new fs_fs. Any way we will put the information for
which version of CVS and SVN this comparison is valid. Since for
example right now CVS support client side renames in repository both
files and folders :)....
Wednesday, October 13, 2004, 8:22:05 PM, you wrote:
kcn> Andrew n marshall <amarshal@ISI.EDU> writes:
>> Searching the web, I came up with this:
>> http://www.pushok.com/soft_svn_vscvs.php
>> but it is undated. Are the comments provided still accurate?
kcn> The statements of fact there are mostly accurate (some of the opinions
kcn> I disagree with, but that's okay). There are a couple of mistakes,
kcn> though. I've CC'd PushOk's webmaster here, in case they want to make
kcn> corrections.
kcn> First, the paragraph about SVN tagging:
kcn> "The SVN developers assert with pride that they have got rid of 3
kcn> measurements by working with tags and branches. In practice it
kcn> means that they have substituted both concepts for a capability of
kcn> copying file(s) or directories within the repository with saving
kcn> the history of changes. That is, both tag creation and branch
kcn> creation are substituted for copying within the repository. From
kcn> the SVN developers' viewpoint, this is very elegant decision, which
kcn> simplifies one's life. However, we think that there is nothing to
kcn> be proud of. As for branches, everything is not so bad, now
kcn> branches are nothing but separate folders in the repository, which
kcn> earlier have had some interconnection. As for tags, everything is
kcn> much worse. Now you cannot tag a code, this function is simply
kcn> missing. Certainly, to some extent this is compensated by universal
kcn> numbering of files in SVN, that is, the whole repository gets the
kcn> version number, but not each separate file. However, we suppose you
kcn> will not deny that it is not very convenient to store a four-digit
kcn> number instead of a symbolic tag."
kcn> The assertion "you cannot tag a code, the function is simply missing"
kcn> is false. I don't know why they think you can't tag code. In
kcn> Subversion, as in CVS, you can tag a working copy to get a repository
kcn> structure that represents the exact mixed-version state of that
kcn> working copy. Or you can tag a state that's already in the
kcn> repository, again just as with CVS.
kcn> I also don't know what the last sentence means. Subversion tags are
kcn> not four-digit numbers, they are UTF8 strings. Any CVS tag name can
kcn> use the same name in Subversion.
kcn> While Subversion's *representation* of tags is slightly different,
kcn> Subversion tags do basically the same things as CVS's. Maybe I'm just
kcn> misunderstanding what PushOk is trying to say above, but the most
kcn> natural interpretations do seem to be false.
kcn> The other mistake is quite understandable, as the FSFS (non-Berkeley)
kcn> repository was probably not available at the time they wrote this:
kcn> "The basis of SVN is a relational database (BerkleyDB). On one
kcn> hand, this settles many problems (for example, concurrent access
kcn> through the file share) and enables new functionalities (for
kcn> example, transactions at operations performance). However, on the
kcn> other hand, data storage now is not transparent, or at least is not
kcn> available for user interference. That is why the utilities for
kcn> 'curing' and 'recovering' of the repository (database) are
kcn> provided."
kcn> Note also that BerkeleyDB is not a "relational database". It's a data
kcn> storage/retrieval mechanism, without relational capabilities.
kcn> Anyway, BerkeleyDB is now one of two options for repository storage.
kcn> I'd also like to point out that the locking/reserved-checkouts
kcn> discussion now under way will soon give us one of the missing features
kcn> PushOk's page talks about the most: CVS's edit/watch functionality.
kcn> -Karl
--
Best regards,
pushok mailto:contact@pushok.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 22 16:36:26 2004