You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Bolstridge, Andrew" <an...@intergraph.com> on 2009/05/19 08:46:55 UTC
Subversion misses (was RE: Subversion vs. StarTeam)
> -----Original Message-----
> From: David Weintraub [mailto:qazwart@gmail.com]
> Sent: Monday, May 18, 2009 6:05 PM
> To: webpost@tigris.org
> Cc: users@subversion.tigris.org; Greg Thomas
> Subject: Re: Subversion vs. StarTeam
>
>
> Hits:
All nice :)
>
> 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.
> * Can be slow on Windows with virus protection on.
> * 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.
> * 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)
> * 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.
> * 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 :)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2309202
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion misses (was RE: Subversion vs. StarTeam)
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: David Weintraub [mailto:qazwart@gmail.com]
> Sent: Tuesday, May 19, 2009 4:19 PM
> To: Bolstridge, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion misses (was RE: Subversion vs. StarTeam)
[snip]
>
> >> * Complex URL scheme makes diffing between branches or tags
> difficult.
>
> 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
>
I've just noticed the Repository root relative URLs feature in 1.6:
http://sub-subversion.blogspot.com/2009/04/why-you-should-use-subversion-16.html
I use Tortoise, so I don't care for this feature too much, it still looks like it'd help you a little:
Svn diff ^/dev/proj/branches/1.0 ^/dev/proj/branches/1.1
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2327143
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion misses (was RE: Subversion vs. StarTeam)
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: Wednesday, May 20, 2009 7:01 AM
> To: Bolstridge, Andrew
> Cc: David Weintraub; users@subversion.tigris.org
> Subject: Re: Subversion misses (was RE: Subversion vs. StarTeam)
>
>
> I'm a dev and I don't think the branching/tagging facilities are as
> good as they should be. I think that a lot of the merge-tracking
> problems
> we have or have had (e.g. subtree merge-info being created where it's
> not
> needed) are due to an insufficient destination between copies of
> directories and branches and tags. Putting all these concepts together
> under "copy" was fine before merge-tracking, but now it creates
> problems
> because e.g. a directory that is the root of a branch is special and
> Subversion doesn't know that.
Going by my understanding of the underlying architecture of
ClearCase/CVS and Subversion, I don't think that a labeling model will
work for Subversion. Instead of labels, Subversion should focus on
baselines. The following analogies aren't perfect, but hopefully
illustrate my point.
ClearCase and CVS support labels easily because each file is a single
versioned object, and that single versioned object contains *all* of the
history, branches, and labels associated with that object. Whenever you
branch the object, you're just updating the branch information contained
in that object.
Since each versioned object's history is self-contained, it's "easy" to
manipulate that history and/or determine merging. It also makes true
renames easy (you move the file and the history goes with it.) The
downside is that if you want to label 1,000 files, you have to crack
open 1,000 versioned objects and updated each one's label/branch/history
(which is very slow.) The other downside is Evil Twins; how do you
merge two independent objects that do not and cannot share
history/ancestry? Long story short, each individual versioned object
contains its full ancestry and history.
In my limited understanding of Subversion's architecture (feel free to
correct me,) each versioned file in SVN is small, ignorant object (the
object's history is *not* contained within the object.) That means
whenever you create a branch/tag/copy/rename of a file object, you get a
new object, and the old and new objects are completely unaware of each
other (whereas in CVS/ClearCase, creating a branch simply updates the
object's history instead of creating a 2nd object.) The SVN objects are
separated at birth and are unaware that they are related. The
relationship (aka ancestry) is tracked via the revisions and by
directory trees. Long story short, branching/tagging in Subversion is
about creating a whole tree of small ignorant objects, and a forest
object tracks the ancestry between trees of files.
Subversion -> Ancestry is centralized. A forest (the ancestry tracker)
contains trees (directories or sets) of files.
CVS/ClearCase -> Individuals maintain their own ancestry. Each file is
an isolated forest of trees of file revisions.
Plus, the labeling paradigms that most folks are familiar with operate
on an individual file basis. Subversion's atomic check-ins feature
doesn't lend itself to labeling individual files.
Therefore, IMHO, you will "never" be able to implement a traditional
labeling paradigm in SVN. Instead, SVN should pursue a baseline
paradigm, IMHO.
Defining what features are necessary to support a baseline paradigm is
left as an exercise to the reader. (Should checking in a set of files
that span multiple baselines be prohibited?)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2352625
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion misses (was RE: Subversion vs. StarTeam)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 20, 2009 at 12:00:43PM +0100, Stefan Sperling wrote:
> On Tue, May 19, 2009 at 05:34:18PM +0100, Bolstridge, Andrew wrote:
> > I was browsing the dev list today, and I found a message from someone
> > who suggested just this - store a label to revnum mapping in revprop
> > 0. Unfortunately he didn't get too favourable a response, possibly
> > because the flamewar of "branching v labelling" was still too fresh.
> >
> > I still think it's a great idea, but I feel the devs think that the
> > branch facilities are so great that they *should* be used for tagging.
>
> I'm a dev and I don't think the branching/tagging facilities are as
> good as they should be. I think that a lot of the merge-tracking problems
> we have or have had (e.g. subtree merge-info being created where it's not
> needed) are due to an insufficient destination between copies of
s/destination/distinction/
Sorry,
Stefan
> directories and branches and tags. Putting all these concepts together
> under "copy" was fine before merge-tracking, but now it creates problems
> because e.g. a directory that is the root of a branch is special and
> Subversion doesn't know that.
>
> I have not been thinking deeply about it yet, and I would
> welcome a discussion on how Subversion could best be made aware
> of were branch and tag boundaries are in the versioned tree.
> For example, we could have:
> svn branch
> svn tag
> commands, which do what svn copy does nowadays, plus creating
> a versioned svn:branch or svn:tag property on the directory
> to mark a boundary.
>
> And we'd need to know what effects these boundaries should have
> on operations like commit, update, merge, copy, move, add, remove,
> and so on. For example, we might not want to allow copies or moves
> across branch boundaries.
>
> But this is really high-level thinking and a lot of work needs
> to be done before a usable proposal can be made.
>
> > I don't like the tag functionality so far - I'd have created thousands
> > of branches to date if we used it (as we release every little change
> > explicitly for our customers)
>
> Well, yes, you have to adjust your workflow to Subversion.
> As with any other tool. Please show me one version control tool
> on the planet that does not assume _any_ particular workflow :)
>
> And note that you can add hook-scripts that make tags read-only by
> rejecting future commits to them.
>
> Stefan
Re: Subversion misses (was RE: Subversion vs. StarTeam)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, May 19, 2009 at 05:34:18PM +0100, Bolstridge, Andrew wrote:
> I was browsing the dev list today, and I found a message from someone
> who suggested just this - store a label to revnum mapping in revprop
> 0. Unfortunately he didn't get too favourable a response, possibly
> because the flamewar of "branching v labelling" was still too fresh.
>
> I still think it's a great idea, but I feel the devs think that the
> branch facilities are so great that they *should* be used for tagging.
I'm a dev and I don't think the branching/tagging facilities are as
good as they should be. I think that a lot of the merge-tracking problems
we have or have had (e.g. subtree merge-info being created where it's not
needed) are due to an insufficient destination between copies of
directories and branches and tags. Putting all these concepts together
under "copy" was fine before merge-tracking, but now it creates problems
because e.g. a directory that is the root of a branch is special and
Subversion doesn't know that.
I have not been thinking deeply about it yet, and I would
welcome a discussion on how Subversion could best be made aware
of were branch and tag boundaries are in the versioned tree.
For example, we could have:
svn branch
svn tag
commands, which do what svn copy does nowadays, plus creating
a versioned svn:branch or svn:tag property on the directory
to mark a boundary.
And we'd need to know what effects these boundaries should have
on operations like commit, update, merge, copy, move, add, remove,
and so on. For example, we might not want to allow copies or moves
across branch boundaries.
But this is really high-level thinking and a lot of work needs
to be done before a usable proposal can be made.
> I don't like the tag functionality so far - I'd have created thousands
> of branches to date if we used it (as we release every little change
> explicitly for our customers)
Well, yes, you have to adjust your workflow to Subversion.
As with any other tool. Please show me one version control tool
on the planet that does not assume _any_ particular workflow :)
And note that you can add hook-scripts that make tags read-only by
rejecting future commits to them.
Stefan
RE: Subversion misses (was RE: Subversion vs. StarTeam)
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: David Weintraub [mailto:qazwart@gmail.com]
> Sent: Tuesday, May 19, 2009 4:19 PM
> To: Bolstridge, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion misses (was RE: Subversion vs. StarTeam)
>
> On Tue, May 19, 2009 at 4:46 AM, Bolstridge, Andrew
> <an...@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.
>
>
> 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.
I was browsing the dev list today, and I found a message from someone who suggested just this - store a label to revnum mapping in revprop 0. Unfortunately he didn't get too favourable a response, possibly because the flamewar of "branching v labelling" was still too fresh.
I still think it's a great idea, but I feel the devs think that the branch facilities are so great that they *should* be used for tagging. The main argument seemed to be a lack of auditing - set the label, you have no means of determining who did it, when or if anyone changed it. (so perhaps it gets stored as a revprop in the project you're labelling, but with the corresponding 'index' written to revprop 0).
I don't like the tag functionality so far - I'd have created thousands of branches to date if we used it (as we release every little change explicitly for our customers)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2315173
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion misses (was RE: Subversion vs. StarTeam)
Posted by David Weintraub <qa...@gmail.com>.
On Tue, May 19, 2009 at 4:46 AM, Bolstridge, Andrew
<an...@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@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2313790
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].