On Tue, May 19, 2009 at 4:46 AM, Bolstridge, Andrew
<andy.bolstridge_at_intergraph.com> wrote:
>> Misses:
>> * Really needs the ability to tag even if tag is just an alias to
>> revision number.
>
> This made me think (at the risk of reopening old wounds) wouldn't it be really,
> really easy to keep a file on the server that stored a list of text 'tags' and a
> corresponding revision number? Then you can very easily 'tag' the repository
> (thanks to the excellent concept that the revision number refers to a unique point-
> in-time) and retrieve a fixed snapshot using a descriptive term instead of having
> to remember the revnum.
We did a similar work around with SCCS which also didn't have the
concept of a tag or label. In SCCS, you created a "tag" by creating a
file with a list of all the files and revisions that were included in
that tag, a shell script to be written to checkout that tag if you
needed it.
And, yo can always just do a log on a tag. That'll get you the revision number:
$ svn log -v --stop-on-copy http://subversion/dev/proj/tags/REL-1.0
------------------------------------------------------------------------
r52505 | svnant | 2009-05-19 08:41:08 -0400 (Tue, 19 May 2009) | 1 line
Changed paths:
A /proj/tags/REL-1.0 (from /modules/adsuite/trunk:52503)
And, when you do a diff between two tags, you can also do this:
$ svn diff http://subversion/dev/proj/trunk
http://subversion/dev/proj/tags/REL-1.0
http://subversion/dev/proj/trunk
http://subversion/dev/proj/tags/REL-1.1
It's just that's it's a bit clumsy, and every time we do this, it
reminds us that Subversion doesn't have true tagging. Oh, even if a
tag is just a revision number alias, you could do things like this:
$ svn diff -rREL-1.0:REL-1.1 http://subversion/dev/proj/trunk
It's just seems like something that should have been engineered into
Subversion from the very beginning. It's like someone wrote down a
list of requirements for a revision control system, and the list was
too long to fit on one page, so tagging was placed on the back, and
the programmer didn't see it.
>> * Complex URL scheme makes diffing between branches or tags difficult.
>
> I've not found this to be a miss too much, my branches are always closely
> related, so changing the location is just a matter of modifying the url slightly.
It's not bad, it's just that the URL structure gets a bit clumsy at
times. Subversion is suppose to be a replacement for CVS, and in CVS,
to diff between to branches, you did this:
$ cvs diff -rBRANCH_1-0,BRANCH_1-1
While in Subversion, it's this:
$ svn diff http://subversion/dev/proj/branches/1.0
http://subversion/dev/proj/branches/1.1
>> * Properties are unsearchable. You can't say "Find me the revision
>> with this property on it.
>
> True, perhaps this is something to be fixed in a tool, like a clucene search. It'd be
> great to integrate such an index in the repository however, but there are one or
> two webapps that sit on top of subversion to provide this kind of searching
> (shame they all seem to be written in Java, like SupoSE or opengrok)
Considering that most revision control systems have nothing like
properties, this is really a minor quibble. How can I complain that
Subversion has a feature, but it is incomplete when most revision
control systems don't even have that feature?
The frustration is that you have this great tool (revision properties
and file properties), and you think of all the things you can do with
it like creating a release status revision property where you can
identify if a particular release has gone to QA or is being smoked
tested, or has been released to a customer, etc.
Then, you realize that's there is no easy way to query for these
properties, so you can't really use them except in the limited way
Subversion uses those properties.
I mean the "svn log" command lists the svn:log, svn:author, and
svn:date revision properties, why not simply list all revision
properties that the user might have set while "svn log" is executing?
I've used ClearCase which has file attributes, and these are
searchable. By the way, ClearCase attributes can be placed upon a file
revision, a file, a branch of a file, or even a tag or branch type.
Almost everything can have an attribute attached to it although only
attributes attached to a file, branch of a file, or a file revision
are truly searchable. Besides, the "cleartool find" query takes a
really long time too.
Getting ahead of myself: I also think that Subversion needs three
different types of attributes. Right now, they have attributes that
can be placed upon a revision of a file, or the entire revision. It
could also use a property that could be placed upon a file (and all
revisions would have that property). That would actually be a better
place to put something like "svn:eol-style" rather than on a
particular revision of a file. It would also be nice to see that
revision properties come in two different types: Copyable where a new
revision would copy the attribute from the previous revision, and
non-copyable where the new revision of a file wouldn't inherit that
type.
>> * No easy way to remove history of either an entire file in the
>> repository or a set of revisions.
>
> Yes, obliterate must be the single number 1 request. Even obliterate-lite that removed the contents would be sufficient.
This is a deal killer for many financial institutions. Sometimes, you
accidentally check in some customer proprietary information, and
having no way to correct that mistake means you can't use Subversion.
Plus, it also means that sites that checkin binaries cannot remove
obsolete revisions. Thus, their repository keeps getting bigger and
bigger.
For example, you might be building a series of dynamically linked
libraries that other programs use for executing anc compiling. You
could simply insist that these are also compiled each time, but you
cannot necessarily guarantee these are being compiled the way your
compiling them.
We work around this issue by using our Maven repository to store
binary files, and then fetch the revision we need. It's not as easy as
simply checking out the binary from Subversion, but it works.
>> * Merging and merge tracking ability is still a bit weak.
>
> I'm not too convinced this is a miss either - except for tree conflicts, it's not
> so bad. Maybe if you're merging all over the place, but I find the mergeinfo
> works for me. Perhaps I don’t stress the merging capabilities too much, but
> then if I did, I'd be stressing my limited capabilites too :)
Merging is extremely difficult to do. I've used lots of revision
control systems, and only ClearCase and Perforce seem to do it right.
However, each one seems to be tuned to a different merge style.
ClearCase is great a merging branches that are long lived and whose
differences get less over time. Perforce is great at merging branches
that are short lived and whose differences are greater over time.
In ClearCase, I create a private branch to do my work without
affecting everyone else, when I am finished my work, I merge the
changes back into the main branch and merge the main branch back into
my private branch. When I am finished, both branches will match. I
keep my private branch as long as I am doing development.
In Perforce, you branch on release, and changes in the release are
merged into the main branch as sets. After a while, the branch dies
because no more changes are taking place on it, and it becomes
obsolete.
Subversion 1.5 was the first attempt to do merge tracking, and it was
okay. I believe Subversion 1.6 was a bit better at it. Maybe
Subversion 1.7 will get it down right.
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2313790
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-19 17:20:31 CEST