> >a) Tell me what tags where placed on /libs/xyz. Efficiently,
> >thats frequently used operation.
>
> Find all instances of libs/xyz in the /tags directory.
>
> Note that this is a frequently used operation in CVS /because/
> it doesn't have atomic commits and global revision numbers.
No. At least for me. I do not tell my colleagues and clients that
I distribute libxxx r34343. I want to tell them that I
distribute libxxx-3.0.4. I want to use numbering scheme to
signal the changes consequences (3.0.4->3.0.5 -patch, 3.0.4 ->
4.0.0 -> revolution).
After all, recently subversion 1.0.1 was published, not
subversion r1934 ...
> >b) Give me the log entries for the changes made between
> > xyz_1-0-8 and xyz_1-0-9. Efficiently.
>
> svn log (repos-url)/tags
>
> It'll give you more than you want, but you'll see all the
> changes you need.
Far more. In fact, If I migrated the CVS repo I currently work
with, I would probably spent a week or so waiting for this
command to finish...
> Not to mention that in SVN, we use revision
> numbers.
Hmm, I am awaiting subversion r2437 - the next version after
subversion 1.0.1 ;-)
> >c) Give me diff between xyz_1-0-8 and xyz_1-0-9. Efficiently
>
> svn diff (repos-url)/tags/xyz_1-0-8 (repos-url)/tags/xyz_1-0-8
>
> And if you don't stop saying "efficiently" I'll ask you to
> create a tag on a 10000-file CVS repository. Efficiently. :-)
The CVS repository I use contains far more than 10000 files. And
tags are placed and analyzed efficiently. Of course those files
are split between many modules, which are separately tagged,
then modules in correct versions are aggregated to release
build.
It does not seem reasonable to me to tag 10000 files as single
entity - whatever verson control system efficiency would be. To
mark and release a version someone must decide where all the
changes are done. It is not possible to understand changes in
10000 files simultaneously. But it is possible for a programmer
to mark a revision of 50-100 file module and it is possible for
the release manager to arrange a build from a 50-100 modules.
> >d) I need to place tag xyz_1-0-10 so it takes the
> >current /libs/xyz version but without the change to the file
> >aaa.cxx commited 3 revisions ago (but with change to the
> > bbb.cxx commited later)
>
> svn up libs/xyz
> svn up -r(HEAD-3) libs/xyz/aaa.cxx
> svn cp libs/xyz (repos-url)/tags/xyz_1-0-10/libs/xyz
OK, this seems nice.
> >e) Reconsider the efficiency of the operations above
> > considering my repository contains 347 separately tagged
> > modules, a lot of which have large history of 100 and more
> > tags
>
> What's there to reconsider? At worst, it's at least as
> efficient as CVS (or ClearCase).
I do not know ClearCase but unfortunately svn lacks something
comparing with CVS. For single reason: in CVS I can take
selected module and operate on it efficiently without relating
to other parts of repository. This module files are here, tags
are here, branches are here, I can operate efficiently on it
whatever the repository around size is.
In SVN tags/<all-the-tags-on-repo> recommended convention kills
immediately, other conventions are imagineable but either
require heavily loaded tags directory which at least RapidSVN
opens looooooooooong, or kills the ability to checkout the trunk
version of the whole repository.
> >e) I don't know anyone to commit to the tag once the tag is
> >placed. What could I do?
> >The case illustration using CVS: trunk /libs/xyz is heavily
> >reorganized, so I do
> > cvs up -r stable_tag /libs/xyz
> >as I use this library while working on something else
> >(in subversion I would svn switch)
> >Some days later I forgot about the tag checkout and do some
> >modification to the files in my xyz working copy. Then I try
> > to commit.
>
> Use access control. Both Apache and svnserve let you set this
> up.
Discussed in reply to Kar's post. Using access control I can
forbid more than I need. It does not seem possible to forbid
commit on tag while keeping an ability of extending tag with the
new file or even just creating the new tag.
> Any of which you can either do with Subversion as it is, or
> change your process slightly. Not a bad thing, I've seen lots
> of processes that are tailored to CVS, but could be simplified
> immensely for Subversion. The trouble is that people are
> usually so against changing the way they work that is't often
> hard to convince them the new way is acthally easier.
As long subversion process requires using repository revision
instead of natural build numbers, it does not seem too
reasonable...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 23:42:41 2004