RE: Subversion vs. StarTeam

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

webpost
We are moving away from StarTeam.  Each upgrade got more difficult to do.  It was as if Borland didn't really want you to do the upgrade instead of paying them to do it.  After we almost pried an upgrade procedure from them for 2008 MSDE from 2005 R2 MSDE we discovered some bugs during our upgrade test.  The show stopper was that the update status would sometimes not be able to resloved a freshly checked out file to a current status.  SVN is the new tool around here we are looking to move to.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2273981

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

webpost
I bet its not free.  Once you get hooked the price goes way up.  We started out much cheaper.  Borland desupports versions and jacks the support cost up according to how hooked they think you are.  Ours support increased by a factor of about 4 one year.

> After much hang-wringing by the local PHBs at work, I finally
> persuaded them to go for Subversion as a SCM solution.
>
> Then, someone did a deal with Borland that gave us access to StarTeam
> for free.
>
> So, the question I'm now being asked is - why Subversion and not
> StarTeam, given that their purchase cost (to us, at least) is the
> same.
>
> Has anyone done a comparison of the two - does anyone have any
> comments, good or bad, about StarTeam?
>
> Thanks,
>
> Greg
> --
> This post represents the views of the author and does
> not necessarily accurately represent the views of BT.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2274063

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

James Greene
Are these your Borland Pain Points?  Did I miss any?

Moving code from one release to the next
Moving client specific one-offs from one release to the next
Getting clean check outs
Updating local working copies in a timely manner (performance)
Performance, Performance, Performance
IDE integration
Licensing
Reporting
Security (allowing people to delete their own files)
Stability
Integration w/ other products
Having an instable trunk
Reverting changes hard
Branching/merging hard
No tooling choices
Bugs
Poorly designed GUI  
Lack of Support

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, May 15, 2009 12:52 PM
To: [hidden email]; Greg Thomas
Subject: RE: Subversion vs. StarTeam

I bet its not free.  Once you get hooked the price goes way up.  We
started out much cheaper.  Borland desupports versions and jacks the
support cost up according to how hooked they think you are.  Ours
support increased by a factor of about 4 one year.

> After much hang-wringing by the local PHBs at work, I finally
> persuaded them to go for Subversion as a SCM solution.
>
> Then, someone did a deal with Borland that gave us access to StarTeam
> for free.
>
> So, the question I'm now being asked is - why Subversion and not
> StarTeam, given that their purchase cost (to us, at least) is the
> same.
>
> Has anyone done a comparison of the two - does anyone have any
> comments, good or bad, about StarTeam?
>
> Thanks,
>
> Greg
> --
> This post represents the views of the author and does not necessarily
> accurately represent the views of BT.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2274063

To unsubscribe from this discussion, e-mail:
[[hidden email]].

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2274417

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Re: Subversion vs. StarTeam

Andy Levy
On Fri, May 15, 2009 at 16:34, James Greene <[hidden email]> wrote:

> Are these your Borland Pain Points?  Did I miss any?
>
> Moving code from one release to the next
> Moving client specific one-offs from one release to the next
> Getting clean check outs
> Updating local working copies in a timely manner (performance)
> Performance, Performance, Performance
> IDE integration
> Licensing
> Reporting
> Security (allowing people to delete their own files)
> Stability
> Integration w/ other products
> Having an instable trunk
> Reverting changes hard
> Branching/merging hard
> No tooling choices
> Bugs
> Poorly designed GUI
> Lack of Support

So what isn't painful? :)

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, May 15, 2009 12:52 PM
> To: [hidden email]; Greg Thomas
> Subject: RE: Subversion vs. StarTeam
>
> I bet its not free.  Once you get hooked the price goes way up.  We
> started out much cheaper.  Borland desupports versions and jacks the
> support cost up according to how hooked they think you are.  Ours
> support increased by a factor of about 4 one year.
>
>> After much hang-wringing by the local PHBs at work, I finally
>> persuaded them to go for Subversion as a SCM solution.
>>
>> Then, someone did a deal with Borland that gave us access to StarTeam
>> for free.
>>
>> So, the question I'm now being asked is - why Subversion and not
>> StarTeam, given that their purchase cost (to us, at least) is the
>> same.
>>
>> Has anyone done a comparison of the two - does anyone have any
>> comments, good or bad, about StarTeam?
>>
>> Thanks,
>>
>> Greg
>> --
>> This post represents the views of the author and does not necessarily
>> accurately represent the views of BT.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
> d=2274063
>
> To unsubscribe from this discussion, e-mail:
> [[hidden email]].
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2274417
>
> To unsubscribe from this discussion, e-mail: [[hidden email]].
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2274468

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

Talkov Roger
In reply to this post by webpost
We moved from StarTeam to Subversion over 5 years ago. StarTeam was
difficult to use at best and horrible to administer. Subversion even at
version 0.9 was way better than StarTeam.
With Subversion our build time went from about 15 minutes to 5.
Both developers and administrators had a much easier time working with
Subversion

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, May 15, 2009 12:44 PM
To: [hidden email]; Greg Thomas
Subject: RE: Subversion vs. StarTeam

We are moving away from StarTeam.  Each upgrade got more difficult to
do.  It was as if Borland didn't really want you to do the upgrade
instead of paying them to do it.  After we almost pried an upgrade
procedure from them for 2008 MSDE from 2005 R2 MSDE we discovered some
bugs during our upgrade test.  The show stopper was that the update
status would sometimes not be able to resloved a freshly checked out
file to a current status.  SVN is the new tool around here we are
looking to move to.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2273981

To unsubscribe from this discussion, e-mail:
[[hidden email]].
Join us for UC4 Integrate 2009, November 8 - 12, San Diego, California.
This email (including any attachments) may contain information which is privileged, confidential, or protected. If you are not the intended recipient, note that any disclosure, copying, distribution, or use of the contents of this message and attached files is prohibited. If you have received this email in error, please notify the sender and delete this email and any attached files.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2275548

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

webpost
In reply to this post by webpost
I'm using Subversion in one building and StarTeam in another. Subversion is fine. StarTeam seems to be OK as long you have a stable development team and never need to upgrade it. The current attempt to upgrade StarTeam has been a nightmare for the sysadmins and SCM person involved. Based on this alone, I would never recommend StarTeam.

I am getting up to speed on Subversion to hopefully replace StarTeam. So far, I find it intuitive and easy to use.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2299757

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Re: Subversion vs. StarTeam

Qazwart
In reply to this post by webpost
I used StarTeam once, and that was enough to convince me not to take
any more StarTeam jobs.

The biggest issue to me is the scripting abilities of StarTeam. You
are suppose to be able to script StarTeam except that the command line
interface is almost impossible to use and is extremely limited. Every
command from the command line must contain the user name, password,
instance, and system -- about 80 characters worth of information.
After doing all that, the output was almost impossible to parse and
the commands that you could run were extremely limited.

There was suppose to be a Unix version, but lo, that ended up being
just the clunky command line interface! On Windows, in the GUI, the
"status" indicators were never accurate. Files that were never edited
were showing up as "updated". Files that needed to be updated were
showing as current. Files that were added weren't always included in
the view.

We also found the defect tracking system pretty useless. We couldn't
add a field we needed although we were told it was possible. They
forgot to tell us that the ability was only in the deluxe version and
not the version we were sold. But, for just a few thousand dollars
more, we could upgrade!

I used Subversion since revision 1.1, and found it much, much easier
to use. Of course, I am a command line geek, so I appreciate the easy
to use command line client. However, TortoiseSVN is an excellent
Windows client. There are a few features I wish Subversion had. It
doesn't really have the concept of tagging (Tags in Subversion are
just branches), and the URL make it more complex than it needs to be
to do branch comparison. It also doesn't allow the complete removal of
files or versions which can be an issue in certain environments.

Hits:
   * Lots of third party tools.
   * Server administration is easy to do.
   * Cost (Free)
   * Documentation is excellent.
   * Flexible setup allows you to use an Apache server and LDAP to
connect to your Windows login server.
   * Hooks allow you to stop commits to the repository before commit
takes place.
   * Properties allow you to easily set special file attributes and behavior.
   * Repository revisioning allows you to drop the daily build labels.
   * Branching and tagging is almost instantaneous, and it's cheap.

Misses:
   * Really needs the ability to tag even if tag is just an alias to
revision number.
   * Can be slow on Windows with virus protection on.
   * Complex URL scheme makes diffing between branches or tags difficult.
   * Properties are unsearchable. You can't say "Find me the revision
with this property on it.
   * No easy way to remove history of either an entire file in the
repository or a set of revisions.
   * Merging and merge tracking ability is still a bit weak.

If your company doesn't mind spending money, you might want to also
look at Perforce too. Perforce is about $800 per user per license, but
I personally like better. It's much faster than Subversion at many
operations, has true tagging, and its merging capabilities are far
superior than Subevrsion's. Perforce's email list has excellent
support, and their phone support is top rate.

Whether or not Perforce is $800 per user per license better is another
question.

To be fair, here are somethings Subversion gets right over Perforce:

* Subversion's properties scheme work better than Perforce's filetype scheme.
* Subversion commands use correct exit codes while Perforce's commands
always return a zero. You need to run a second command to see whether
or not the command actually worked (or use the API).
* Perforce doesn't track directory moves or renames (except in a
branching concept). If you move a file to a different directory,
delete a file, or rename a file in one branch, but not in another, you
have to manually modify the "branch type".
* Perforce uses the concept of changelists, so when you edit a file,
you have to "mark it" as edited in a particular changelist before you
actually modify the file. Plus, the whole view concept can be quite
tricky for developers to understand.

On Fri, May 15, 2009 at 3:43 PM,  <[hidden email]> wrote:
> We are moving away from StarTeam.  Each upgrade got more difficult to do.  It was as if Borland didn't really want you to do the upgrade instead of paying them to do it.  After we almost pried an upgrade procedure from them for 2008 MSDE from 2005 R2 MSDE we discovered some bugs during our upgrade test.  The show stopper was that the update status would sometimes not be able to resloved a freshly checked out file to a current status.  SVN is the new tool around here we are looking to move to.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2273981
>
> To unsubscribe from this discussion, e-mail: [[hidden email]].
>



--
David Weintraub
[hidden email]

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2301673

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

webpost
In reply to this post by webpost
Thanks for the posts.  That is the Borland StarTeam point for us as well, difficult or impossible to upgrade.  Once we got a test copy upgraded it didn't take long to find bugs that Borland has no plans to fix.

> I'm using Subversion in one building and StarTeam in another. Subversion is fine. StarTeam seems to be OK as long you have a stable development team and never need to upgrade it. The current attempt to upgrade StarTeam has been a nightmare for the sysadmins and SCM person involved. Based on this alone, I would never recommend StarTeam.
>
> I am getting up to speed on Subversion to hopefully replace StarTeam. So far, I find it intuitive and easy to use.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2302204

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Subversion misses (was RE: Subversion vs. StarTeam)

Bolstridge, Andrew
In reply to this post by Qazwart
> -----Original Message-----
> From: David Weintraub [mailto:[hidden email]]
> Sent: Monday, May 18, 2009 6:05 PM
> To: [hidden email]
> Cc: [hidden email]; 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: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Re: Subversion misses (was RE: Subversion vs. StarTeam)

Qazwart
On Tue, May 19, 2009 at 4:46 AM, Bolstridge, Andrew
<[hidden email]> 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
[hidden email]

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2313790

To unsubscribe from this discussion, e-mail: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion misses (was RE: Subversion vs. StarTeam)

Bolstridge, Andrew
> -----Original Message-----
> From: David Weintraub [mailto:[hidden email]]
> Sent: Tuesday, May 19, 2009 4:19 PM
> To: Bolstridge, Andrew
> Cc: [hidden email]
> Subject: Re: Subversion misses (was RE: Subversion vs. StarTeam)
>
> On Tue, May 19, 2009 at 4:46 AM, Bolstridge, Andrew
> <[hidden email]> 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: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion misses (was RE: Subversion vs. StarTeam)

Bolstridge, Andrew
In reply to this post by Qazwart
> -----Original Message-----
> From: David Weintraub [mailto:[hidden email]]
> Sent: Tuesday, May 19, 2009 4:19 PM
> To: Bolstridge, Andrew
> Cc: [hidden email]
> 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: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Re: Subversion misses (was RE: Subversion vs. StarTeam)

Stefan Sperling
In reply to this post by Bolstridge, Andrew
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

Reply | Threaded
Open this post in threaded view
|

Re: Subversion misses (was RE: Subversion vs. StarTeam)

Stefan Sperling
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

Reply | Threaded
Open this post in threaded view
|

RE: Subversion misses (was RE: Subversion vs. StarTeam)

Reedick, Andrew-2
In reply to this post by Stefan Sperling
> -----Original Message-----
> From: Stefan Sperling [mailto:[hidden email]]
> Sent: Wednesday, May 20, 2009 7:01 AM
> To: Bolstridge, Andrew
> Cc: David Weintraub; [hidden email]
> 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: [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

RE: Subversion vs. StarTeam

Bolstridge, Andrew
In reply to this post by Qazwart
Hi all.

        Does anyone have any experience using Serena Dimensions? I'm really interested in a comparison between them and Collabnet's Teamforge (or any other change management toolset), but any information you can give me about them would be useful.

Thanks.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410125

To unsubscribe from this discussion, e-mail: [[hidden email]].