You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steven Comfort <St...@uec.co.za> on 2007/04/24 10:31:11 UTC
Subversion vs Clearcase
Hi all,
After spending considerable effort getting SVN established at our organization, and hosting very successful multi-site developments, it appears that a dictat has come down from on high stating that "Thou shalt use Clearcase".
I've been subscribed to this mailing list for about 5 months, and have noted that a number of organizations are migrating in the opposite direction i.e ClearCase to Subversion.
I have a strong feeling that we'll be making a huge mistake by opting for Clearcase, but am looking for some stats to back this feeling up. Has anyone done any studies in this area? I'd love to hear from any organizations that have ditched Clearcase...
Best regards
Steve Comfort
________________________________
E-Mail Disclaimer : http://www.altron.co.za/email.asp
Should you have any questions regarding this e-mail legal notice please contact us on
1. Telephone number : +27116453600
2. Fax number : +27117263009
3. E-mail address : info@altron.co.za
Re: Subversion vs Clearcase
Posted by Raman Gupta <ro...@fastmail.fm>.
Justin Johnson wrote:
> On 4/27/07, Raman Gupta <ra...@rocketraman.com> wrote:
>> Justin Johnson wrote:
>> > True, svnmerge.py adds much of the needed functionality. It doesn't
>> > allow you to cherry pick a portion of a change set yet, but I'm
>> > looking forward to 1.5. No complaining here, just stating the facts
>> > so Steve is informed.
>>
>> Yes it does, as long the smallest unit you are considering within
>> "change set" is a revision.
>
> I'm not sure what you mean by this. When I said change set I was
> referring to a revision of the repository. Since the revision number
> is tracked in a property on the branch with no indication of which
> files in that revision have been merged, you must merge the change set
> (i.e. revision) as a whole and not single elements within the change
> set.
Ok, I misinterpreted your message -- as you stated, currently
svnmerge.py does not support partial merging of single revisions.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Justin Johnson <ju...@gmail.com>.
On 4/27/07, Raman Gupta <ra...@rocketraman.com> wrote:
> Justin Johnson wrote:
> > True, svnmerge.py adds much of the needed functionality. It doesn't
> > allow you to cherry pick a portion of a change set yet, but I'm
> > looking forward to 1.5. No complaining here, just stating the facts
> > so Steve is informed.
>
> Yes it does, as long the smallest unit you are considering within
> "change set" is a revision.
I'm not sure what you mean by this. When I said change set I was
referring to a revision of the repository. Since the revision number
is tracked in a property on the branch with no indication of which
files in that revision have been merged, you must merge the change set
(i.e. revision) as a whole and not single elements within the change
set.
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Raman Gupta <ra...@rocketraman.com>.
Justin Johnson wrote:
> True, svnmerge.py adds much of the needed functionality. It doesn't
> allow you to cherry pick a portion of a change set yet, but I'm
> looking forward to 1.5. No complaining here, just stating the facts
> so Steve is informed.
Yes it does, as long the smallest unit you are considering within
"change set" is a revision.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Subversion vs Clearcase
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
> >
> > 1. After you get used to it, keeping track of revision
> boundries when
> > merging isn't *that* bad. 2. It seems that svnmerge.py works fairly
> > well, though we've just experimented with it so far so.
> There may be
> > issues we don't know about. 3. Finally, merge tracking
> supposedly is
> > coming in 1.5.
>
> True, svnmerge.py adds much of the needed functionality. It
> doesn't allow you to cherry pick a portion of a change set
> yet, but I'm looking forward to 1.5. No complaining here,
> just stating the facts so Steve is informed.
I haven't used cherry-picking functionality yet, but according to
http://www.orcaware.com/svn/wiki/Svnmerge.py, cherry picking is
supported.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: Subversion vs Clearcase
Posted by Justin Johnson <ju...@gmail.com>.
On 4/27/07, Irvine, Chuck R [EQ] <Ch...@embarq.com> wrote:
> [snip]
> >
> > In my opinion there are two main features that Subversion
> > lacks in comparison with ClearCase. Without these I think
> > there are valid cases where a team would not want to switch
> > to Subversion.
>
> These are things are a big deal to us as well, but...
>
> >
> > 1) Lack of merge tracking
>
> 1. After you get used to it, keeping track of revision boundries when
> merging isn't *that* bad.
> 2. It seems that svnmerge.py works fairly well, though we've just
> experimented with it so far so. There may be issues we don't know about.
> 3. Finally, merge tracking supposedly is coming in 1.5.
True, svnmerge.py adds much of the needed functionality. It doesn't
allow you to cherry pick a portion of a change set yet, but I'm
looking forward to 1.5. No complaining here, just stating the facts
so Steve is informed.
> >
> > ClearCase has very mature merge tracking capabilities (via
> > merge arrows). Subversion has none. You must track what has
> > previously been merged either by hand or do all merges in the
> > svnmerge.py script.
> >
> > 2) True rename support
>
> Hmmmm..... Yes this is problem for the reason. :-|
>
> >
> > See
> > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copycha
> > nges.html#svn.branchmerge.copychanges.bestprac.moves.
> > This problem means that merging from one branch to another
> > when moves or renames have occurred can be an extremely
> > manual process and in some common cases you could accidently
> > delete changes from one branch. Of course those changes are
> > still in the repository, but the merge deletes them without warning.
>
> Actually, the same underlying problem, can cause code loss from the
> latest revision even in the context of a single development stream, i.e.
> the trunk, when one user renames something and another makes edits and
> does an update.
Right, this is a problem as well.
> >
> > So if a team can live with ClearCase's limitations regarding
> > how close the client is to the server and they have intense
> > branching and merging requirements, my opinion is that
> > ClearCase is a better fit.
>
> Another factor is the cost of ClearCase in terms of initial cost, annual
> maintenance, hardware, networking enhancements, internal support costs.
> All of this can add up to a substantial sum. If you start adding CC's
> replication functionality, costs are even more substantial.
>
> >
> > Justin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Subversion vs Clearcase
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
[snip]
>
> In my opinion there are two main features that Subversion
> lacks in comparison with ClearCase. Without these I think
> there are valid cases where a team would not want to switch
> to Subversion.
These are things are a big deal to us as well, but...
>
> 1) Lack of merge tracking
1. After you get used to it, keeping track of revision boundries when
merging isn't *that* bad.
2. It seems that svnmerge.py works fairly well, though we've just
experimented with it so far so. There may be issues we don't know about.
3. Finally, merge tracking supposedly is coming in 1.5.
>
> ClearCase has very mature merge tracking capabilities (via
> merge arrows). Subversion has none. You must track what has
> previously been merged either by hand or do all merges in the
> svnmerge.py script.
>
> 2) True rename support
Hmmmm..... Yes this is problem for the reason. :-|
>
> See
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copycha
> nges.html#svn.branchmerge.copychanges.bestprac.moves.
> This problem means that merging from one branch to another
> when moves or renames have occurred can be an extremely
> manual process and in some common cases you could accidently
> delete changes from one branch. Of course those changes are
> still in the repository, but the merge deletes them without warning.
Actually, the same underlying problem, can cause code loss from the
latest revision even in the context of a single development stream, i.e.
the trunk, when one user renames something and another makes edits and
does an update.
>
> So if a team can live with ClearCase's limitations regarding
> how close the client is to the server and they have intense
> branching and merging requirements, my opinion is that
> ClearCase is a better fit.
Another factor is the cost of ClearCase in terms of initial cost, annual
maintenance, hardware, networking enhancements, internal support costs.
All of this can add up to a substantial sum. If you start adding CC's
replication functionality, costs are even more substantial.
>
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Justin Johnson <ju...@gmail.com>.
On 4/24/07, Steven Comfort <St...@uec.co.za> wrote:
>
>
> Hi all,
>
> After spending considerable effort getting SVN established at our
> organization, and hosting very successful multi-site developments, it
> appears that a dictat has come down from on high stating that "Thou shalt
> use Clearcase".
>
> I've been subscribed to this mailing list for about 5 months, and have noted
> that a number of organizations are migrating in the opposite direction i.e
> ClearCase to Subversion.
>
> I have a strong feeling that we'll be making a huge mistake by opting for
> Clearcase, but am looking for some stats to back this feeling up. Has anyone
> done any studies in this area? I'd love to hear from any organizations that
> have ditched Clearcase...
In my opinion there are two main features that Subversion lacks in
comparison with ClearCase. Without these I think there are valid
cases where a team would not want to switch to Subversion.
1) Lack of merge tracking
ClearCase has very mature merge tracking capabilities (via merge
arrows). Subversion has none. You must track what has previously
been merged either by hand or do all merges in the svnmerge.py script.
2) True rename support
See http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.moves.
This problem means that merging from one branch to another when moves
or renames have occurred can be an extremely manual process and in
some common cases you could accidently delete changes from one branch.
Of course those changes are still in the repository, but the merge
deletes them without warning.
So if a team can live with ClearCase's limitations regarding how close
the client is to the server and they have intense branching and
merging requirements, my opinion is that ClearCase is a better fit.
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Andy Levy <an...@gmail.com>.
On 4/27/07, Chris.Fouts@qimonda.com <Ch...@qimonda.com> wrote:
> >-----Original Message-----
> >From: Andy Levy [mailto:andy.levy@gmail.com]
> >Sent: Friday, April 27, 2007 12:00 PM
> >To: Fouts Christopher (QNA RTP PT PREV)
> >Cc: users@subversion.tigris.org
> >Subject: Re: Subversion vs Clearcase
> >
> >On 4/27/07, Chris.Fouts@qimonda.com <Ch...@qimonda.com> wrote:
> >>
> >> >-----Original Message-----
> >> >From: Les Mikesell [mailto:lesmikesell@gmail.com]
> >> >Sent: Friday, April 27, 2007 11:45 AM
> >> >To: Fouts Christopher (QNA RTP PT PREV)
> >> >Cc: users@subversion.tigris.org
> >> >Subject: Re: Subversion vs Clearcase
> >> >
> >> >Chris.Fouts@qimonda.com wrote:
> >> >> SVN would be my favorite app. only if it had a concept of SCM. If
> >> >> it does, can someone shed light on it?
> >> >
> >> >That might be easier if you explained what you think is
> >missing. You
> >> >can make branches to isolate work and tags to be able to recall any
> >> >version by a name. What else do you need?
> >> >
> >>
> >> I really like the power of a configuration spec in CC; is there
> >> something similar in SVN? Thanks!
> >
> >For the benefit of people who've never used or seen CC (or
> >whatever the compared tool du jour is), can folks please
> >briefly explain *what* a particular feature does, instead of
> >just throwing a name out (if the name doesn't make it
> >blindingly obvious)?
> >
>
> My bad! CC has a config spec that provides a way to pick and
> choose, or "filter" what files can be in a build. What's neat
> about it, I can mix and match any trunked, tagged, or branched
> files in the repos. For example, I can
>
> element foo.c /b_R1/2
> element * /b_R1/latest
> element * /main/latest
>
> This means, in this order...
> 1. Use v2 of foo.c from the b_R1 branch
> 2. Use b_R1 branch for the rest of the files,
> if the files are on that branch
> 3. Use the /main/latest version of the rest of
> files
>
> If I remove the second line, I'll ignore the b_R1 branch, except
> for foo.c /b_R1/2, ON THE FLY.
>
> I may have added the top line because I found a problem with
> the /b_R1/latest version of foo.c (say v3), so I elected to
> use v2 instead.
>
> I can "commit" changes using config specs.
Oddly enough, your email came in while I was on the phone with someone
in a situation where this would be the perfect solution.
Thanks for the explanation!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
>-----Original Message-----
>From: Les Mikesell [mailto:lesmikesell@gmail.com]
>Sent: Monday, April 30, 2007 2:10 PM
>To: Fouts Christopher (QNA RTP PT PREV)
>Cc: users@subversion.tigris.org
>Subject: Re: Subversion vs Clearcase
>
>Chris.Fouts@qimonda.com wrote:
>
>> Don't get me wrong, I really like SVN - espcially for the price! I'm
>> appreciative of the fact that people are passionate enough
>to come up
>> with an app. that I use everyday in my company. I'm just merely
>> pointing out the one SCM feature I like about other similar apps.
>
>Just think of branching as the main SCM strategy in svn and it
>may make more sense. If you want to work on something that
>you don't want to match an existing revision, put it together
>in a new branch.
>
>Also, if you are starting a new project from scratch, you
>might want to organize it differently for svn. The possible
>ways to mix components are the 'svn switch' approach at
>directory levels in the same tree, or using externals to pull
>in things that are not in the same tree in the repository.
>The latter approach is probably better for libraries or code
>shared by other projects where you want the option of floating
>with the development HEAD or locking to a known revision (in
>early stages you may need to coordinate work in both, but as
>you approach a release you probably want to tie them to tags
>to avoid problems from future changes that might be made for
>other projects.
>
>--
> Les Mikesell
> lesmikesell@gmail.com
>
Thanks, I'll try these ideas!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Les Mikesell <le...@gmail.com>.
Chris.Fouts@qimonda.com wrote:
> Don't get me wrong, I really like SVN - espcially for the price! I'm
> appreciative of the fact that people are passionate enough to come
> up with an app. that I use everyday in my company. I'm just merely
> pointing out the one SCM feature I like about other similar apps.
Just think of branching as the main SCM strategy in svn and it may make
more sense. If you want to work on something that you don't want to
match an existing revision, put it together in a new branch.
Also, if you are starting a new project from scratch, you might want to
organize it differently for svn. The possible ways to mix components
are the 'svn switch' approach at directory levels in the same tree, or
using externals to pull in things that are not in the same tree in the
repository. The latter approach is probably better for libraries or
code shared by other projects where you want the option of floating with
the development HEAD or locking to a known revision (in early stages you
may need to coordinate work in both, but as you approach a release you
probably want to tie them to tags to avoid problems from future changes
that might be made for other projects.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
>-----Original Message-----
>From: Les Mikesell [mailto:lesmikesell@gmail.com]
>Sent: Monday, April 30, 2007 1:06 PM
>To: Fouts Christopher (QNA RTP PT PREV)
>Cc: users@subversion.tigris.org
>Subject: Re: Subversion vs Clearcase
>
(snip a lot)
>But you didn't answer the question of where it sends a commit
>to a file you specified as a backrev. Does/should this go to the HEAD?
>
(snip a lot)
Yes, if I check out foo.c /b_R1/2, make changes, and then commit,
it would go to the HEAD of b_R1. So if /b_R1/3 exists as the current
HEAD, it will be committed as /b_R1/4.
Don't get me wrong, I really like SVN - espcially for the price! I'm
appreciative of the fact that people are passionate enough to come
up with an app. that I use everyday in my company. I'm just merely
pointing out the one SCM feature I like about other similar apps.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Les Mikesell <le...@gmail.com>.
Chris.Fouts@qimonda.com wrote:
>>
>>>>> My bad! CC has a config spec that provides a way to pick
>> and choose,
>>>>> or "filter" what files can be in a build. What's neat about
>>>> it, I can
>>>>> mix and match any trunked, tagged, or branched files in the
>>>> repos. For
>>>>> example, I can
>>>>>
>>>>> element foo.c /b_R1/2
>>>>> element * /b_R1/latest
>>>>> element * /main/latest
>>>>>
>>>>> This means, in this order...
>>>>> 1. Use v2 of foo.c from the b_R1 branch 2. Use b_R1 branch for the
>>>>> rest of the files,
>>>>> if the files are on that branch
>>>>> 3. Use the /main/latest version of the rest of
>>>>> files
>>>>>
>>>>> If I remove the second line, I'll ignore the b_R1 branch,
>> except for
>>>>> foo.c /b_R1/2, ON THE FLY.
>>>>>
>>>>> I may have added the top line because I found a problem with the
>>>>> /b_R1/latest version of foo.c (say v3), so I elected to use v2
>>>>> instead.
>>>>>
>>>>> I can "commit" changes using config specs.
>>>> Creating a Complex Tag
>>>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.htm
>>>> l#svn.branchmerge.tags.mkcomplex
>>>>
>>>> It is probably more effort to set up with Subversion, but doable.
>>>>
>>> Thanks for the link, but I read it and don't quite follow. Please
>>> explain how complex tags can be act like a "confg spec?"
>>>
>>> - How can I use it to checkout the files I need, and then work with
>>> those files?
>> Start by checking out the version with the largest portion of
>> the files you want - probably the head of the trunk or a
>> branch. Then selectively
>> update the parts you want to earlier revisions. You could
>> do that in a script or batch file if you plan to repeat it,
>> but you'd probably be better off branching if you expect to
>> re-use this combination.
>
> Can I mix/match trunked/branched/tagged files in my workspace?
> For example, will this work?
> svn co //repos/trunk myws
> svn co //repos/branch/dir1 myws
> svn co //repos/tags/dir2/file1 myws
Not exactly. Note that it is trivial to 'svnadmin create' a file repo
for testing so you know exactly what to expect. Probably easier than
asking here... You can, at directory levels, 'svn switch' to different
branches and update after the initial checkout. This will automatically
update the working copy directory to match the switched repository and
subsequent commits will go back there. Within a directory you can 'svn
update -r ### file' to force an update to an earlier revision out of the
same repository branch. I don't think you can pull an arbitrary
backrev of a single file from some other branch and maintain versioning
(you could export it and copy where you wanted, of course). Svn likes
to work atomically with directories.
> If I then make changes to a file exclusively in the
> //repos/trunk
> //repos/branch/dir1
> //repos/tags/dir2/file1
> and do an "svn commit", will the changes go in the
> //repos/trunk
> //repos/branch/dir1
> //repos/tags/dir2/file1
> correct?
Switched lower level directories commit back the their corresponding
branches. You can't control it at the file level.
>>> - How can I use it to tag (label?) those files?
>> You can "svn copy" your current working copy to a tag - or to
>> start a new branch. Your working copy does not have to match
>> any existing revision when you do this.
>
> Thanks for the reminder! Say I want to tag my above workspace
> as R1. I expect the R1 tag to be applied to
> the //repos/trunk files
> the //repos/branch/dir1 files
> the //repos/tags/dir2/file1 file
> correct?
Svn tags are not labels applied to existing versions (a long-running
discussion here...). A tag in svn is a 'cheap copy' that gets its own
name and what appears to be a copy of everything included in that tagged
version. It is identical to a branch except for the convention that you
don't commit changes back to it. So, if you copy your working copy to a
tag, you get whatever assortment of files you had assembled there and
you will be able to reproduce that set by checking out the tag.
However, you won't be able to look back from future trunk revisions and
see where that tag was applied.
>>> - How can I use it to then commit the changes?
>> If you branch, you'd just switch to the branch and work
>> normally. What does clearcase do when you commit to something
>> you specified as a backrev of a file?
>>
>
> CC uses the config spec I alluded to for ALL transactions!
> So if I checkout foo.c, it will checkout the b_R1/2 version
> because of my first rule. If I remove that rule, it will
> checkout the b_R1/latest (3 in this case) version. BTW, I'll
> have to add the
> element * CHECKEDOUT
> rule to see my checkout out version of a file first.
But you didn't answer the question of where it sends a commit to a file
you specified as a backrev. Does/should this go to the HEAD?
> This flexibility is one feature I really miss. It factors into
> CC being an "software configuration manager, or SCM" rather than
> just a revision control system. Perforce has a similar feauture,
> but NOT as convenient.
In svn, you would normally assemble the parts you want, copy them to a
branch to hold them together for future work, making tag snapshots for
anything you want to be able to reproduce exactly by name. When/if you
want the changes in this branch to apply elsewhere, you merge them.
Other than the directory vs. file aspect (and the fact you have to track
merge revisions yourself in the current svn) it doesn't sound much more
cumbersome. Just keep in mind that branches are cheap and you can use
them for any assortment of things that you don't want to match trunk
versions.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
>-----Original Message-----
>From: Les Mikesell [mailto:lesmikesell@gmail.com]
>Sent: Monday, April 30, 2007 11:29 AM
>To: Fouts Christopher (QNA RTP PT PREV)
>Cc: users@subversion.tigris.org
>Subject: Re: Subversion vs Clearcase
>
>Chris.Fouts@qimonda.com wrote:
>
>>>> My bad! CC has a config spec that provides a way to pick
>and choose,
>>>> or "filter" what files can be in a build. What's neat about
>>> it, I can
>>>> mix and match any trunked, tagged, or branched files in the
>>> repos. For
>>>> example, I can
>>>>
>>>> element foo.c /b_R1/2
>>>> element * /b_R1/latest
>>>> element * /main/latest
>>>>
>>>> This means, in this order...
>>>> 1. Use v2 of foo.c from the b_R1 branch 2. Use b_R1 branch for the
>>>> rest of the files,
>>>> if the files are on that branch
>>>> 3. Use the /main/latest version of the rest of
>>>> files
>>>>
>>>> If I remove the second line, I'll ignore the b_R1 branch,
>except for
>>>> foo.c /b_R1/2, ON THE FLY.
>>>>
>>>> I may have added the top line because I found a problem with the
>>>> /b_R1/latest version of foo.c (say v3), so I elected to use v2
>>>> instead.
>>>>
>>>> I can "commit" changes using config specs.
>>> Creating a Complex Tag
>>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.htm
>>> l#svn.branchmerge.tags.mkcomplex
>>>
>>> It is probably more effort to set up with Subversion, but doable.
>>>
>
>> Thanks for the link, but I read it and don't quite follow. Please
>> explain how complex tags can be act like a "confg spec?"
>>
>> - How can I use it to checkout the files I need, and then work with
>> those files?
>
>Start by checking out the version with the largest portion of
>the files you want - probably the head of the trunk or a
>branch. Then selectively
> update the parts you want to earlier revisions. You could
>do that in a script or batch file if you plan to repeat it,
>but you'd probably be better off branching if you expect to
>re-use this combination.
Can I mix/match trunked/branched/tagged files in my workspace?
For example, will this work?
svn co //repos/trunk myws
svn co //repos/branch/dir1 myws
svn co //repos/tags/dir2/file1 myws
If I then make changes to a file exclusively in the
//repos/trunk
//repos/branch/dir1
//repos/tags/dir2/file1
and do an "svn commit", will the changes go in the
//repos/trunk
//repos/branch/dir1
//repos/tags/dir2/file1
correct?
>
>> - How can I use it to tag (label?) those files?
>
>You can "svn copy" your current working copy to a tag - or to
>start a new branch. Your working copy does not have to match
>any existing revision when you do this.
Thanks for the reminder! Say I want to tag my above workspace
as R1. I expect the R1 tag to be applied to
the //repos/trunk files
the //repos/branch/dir1 files
the //repos/tags/dir2/file1 file
correct?
>
>> - How can I use it to then commit the changes?
>
>If you branch, you'd just switch to the branch and work
>normally. What does clearcase do when you commit to something
>you specified as a backrev of a file?
>
CC uses the config spec I alluded to for ALL transactions!
So if I checkout foo.c, it will checkout the b_R1/2 version
because of my first rule. If I remove that rule, it will
checkout the b_R1/latest (3 in this case) version. BTW, I'll
have to add the
element * CHECKEDOUT
rule to see my checkout out version of a file first.
This flexibility is one feature I really miss. It factors into
CC being an "software configuration manager, or SCM" rather than
just a revision control system. Perforce has a similar feauture,
but NOT as convenient.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Les Mikesell <le...@gmail.com>.
Chris.Fouts@qimonda.com wrote:
>>> My bad! CC has a config spec that provides a way to pick and choose,
>>> or "filter" what files can be in a build. What's neat about
>> it, I can
>>> mix and match any trunked, tagged, or branched files in the
>> repos. For
>>> example, I can
>>>
>>> element foo.c /b_R1/2
>>> element * /b_R1/latest
>>> element * /main/latest
>>>
>>> This means, in this order...
>>> 1. Use v2 of foo.c from the b_R1 branch 2. Use b_R1 branch for the
>>> rest of the files,
>>> if the files are on that branch
>>> 3. Use the /main/latest version of the rest of
>>> files
>>>
>>> If I remove the second line, I'll ignore the b_R1 branch, except for
>>> foo.c /b_R1/2, ON THE FLY.
>>>
>>> I may have added the top line because I found a problem with the
>>> /b_R1/latest version of foo.c (say v3), so I elected to use v2
>>> instead.
>>>
>>> I can "commit" changes using config specs.
>> Creating a Complex Tag
>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.htm
>> l#svn.branchmerge.tags.mkcomplex
>>
>> It is probably more effort to set up with Subversion, but doable.
>>
> Thanks for the link, but I read it and don't quite follow. Please
> explain how complex tags can be act like a "confg spec?"
>
> - How can I use it to checkout the files I need, and then work with
> those files?
Start by checking out the version with the largest portion of the files
you want - probably the head of the trunk or a branch. Then selectively
update the parts you want to earlier revisions. You could do that in
a script or batch file if you plan to repeat it, but you'd probably be
better off branching if you expect to re-use this combination.
> - How can I use it to tag (label?) those files?
You can "svn copy" your current working copy to a tag - or to start a
new branch. Your working copy does not have to match any existing
revision when you do this.
> - How can I use it to then commit the changes?
If you branch, you'd just switch to the branch and work normally. What
does clearcase do when you commit to something you specified as a
backrev of a file?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
>-----Original Message-----
>From: Jared Silva [mailto:jayrod@gmail.com]
>Sent: Friday, April 27, 2007 1:51 PM
>To: users
>Subject: Re: Subversion vs Clearcase
>
>Chris.Fouts@qimonda.com wrote:
>> My bad! CC has a config spec that provides a way to pick and choose,
>> or "filter" what files can be in a build. What's neat about
>it, I can
>> mix and match any trunked, tagged, or branched files in the
>repos. For
>> example, I can
>>
>> element foo.c /b_R1/2
>> element * /b_R1/latest
>> element * /main/latest
>>
>> This means, in this order...
>> 1. Use v2 of foo.c from the b_R1 branch 2. Use b_R1 branch for the
>> rest of the files,
>> if the files are on that branch
>> 3. Use the /main/latest version of the rest of
>> files
>>
>> If I remove the second line, I'll ignore the b_R1 branch, except for
>> foo.c /b_R1/2, ON THE FLY.
>>
>> I may have added the top line because I found a problem with the
>> /b_R1/latest version of foo.c (say v3), so I elected to use v2
>> instead.
>>
>> I can "commit" changes using config specs.
>
>Creating a Complex Tag
>http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.htm
>l#svn.branchmerge.tags.mkcomplex
>
>It is probably more effort to set up with Subversion, but doable.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
Thanks for the link, but I read it and don't quite follow. Please
explain how complex tags can be act like a "confg spec?"
- How can I use it to checkout the files I need, and then work with
those files?
- How can I use it to tag (label?) those files?
- How can I use it to then commit the changes?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Jared Silva <ja...@gmail.com>.
Chris.Fouts@qimonda.com wrote:
> My bad! CC has a config spec that provides a way to pick and
> choose, or "filter" what files can be in a build. What's neat
> about it, I can mix and match any trunked, tagged, or branched
> files in the repos. For example, I can
>
> element foo.c /b_R1/2
> element * /b_R1/latest
> element * /main/latest
>
> This means, in this order...
> 1. Use v2 of foo.c from the b_R1 branch
> 2. Use b_R1 branch for the rest of the files,
> if the files are on that branch
> 3. Use the /main/latest version of the rest of
> files
>
> If I remove the second line, I'll ignore the b_R1 branch, except
> for foo.c /b_R1/2, ON THE FLY.
>
> I may have added the top line because I found a problem with
> the /b_R1/latest version of foo.c (say v3), so I elected to
> use v2 instead.
>
> I can "commit" changes using config specs.
Creating a Complex Tag
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html#svn.branchmerge.tags.mkcomplex
It is probably more effort to set up with Subversion, but doable.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
>-----Original Message-----
>From: Andy Levy [mailto:andy.levy@gmail.com]
>Sent: Friday, April 27, 2007 12:00 PM
>To: Fouts Christopher (QNA RTP PT PREV)
>Cc: users@subversion.tigris.org
>Subject: Re: Subversion vs Clearcase
>
>On 4/27/07, Chris.Fouts@qimonda.com <Ch...@qimonda.com> wrote:
>>
>> >-----Original Message-----
>> >From: Les Mikesell [mailto:lesmikesell@gmail.com]
>> >Sent: Friday, April 27, 2007 11:45 AM
>> >To: Fouts Christopher (QNA RTP PT PREV)
>> >Cc: users@subversion.tigris.org
>> >Subject: Re: Subversion vs Clearcase
>> >
>> >Chris.Fouts@qimonda.com wrote:
>> >> SVN would be my favorite app. only if it had a concept of SCM. If
>> >> it does, can someone shed light on it?
>> >
>> >That might be easier if you explained what you think is
>missing. You
>> >can make branches to isolate work and tags to be able to recall any
>> >version by a name. What else do you need?
>> >
>>
>> I really like the power of a configuration spec in CC; is there
>> something similar in SVN? Thanks!
>
>For the benefit of people who've never used or seen CC (or
>whatever the compared tool du jour is), can folks please
>briefly explain *what* a particular feature does, instead of
>just throwing a name out (if the name doesn't make it
>blindingly obvious)?
>
My bad! CC has a config spec that provides a way to pick and
choose, or "filter" what files can be in a build. What's neat
about it, I can mix and match any trunked, tagged, or branched
files in the repos. For example, I can
element foo.c /b_R1/2
element * /b_R1/latest
element * /main/latest
This means, in this order...
1. Use v2 of foo.c from the b_R1 branch
2. Use b_R1 branch for the rest of the files,
if the files are on that branch
3. Use the /main/latest version of the rest of
files
If I remove the second line, I'll ignore the b_R1 branch, except
for foo.c /b_R1/2, ON THE FLY.
I may have added the top line because I found a problem with
the /b_R1/latest version of foo.c (say v3), so I elected to
use v2 instead.
I can "commit" changes using config specs.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Andy Levy <an...@gmail.com>.
On 4/27/07, Chris.Fouts@qimonda.com <Ch...@qimonda.com> wrote:
>
> >-----Original Message-----
> >From: Les Mikesell [mailto:lesmikesell@gmail.com]
> >Sent: Friday, April 27, 2007 11:45 AM
> >To: Fouts Christopher (QNA RTP PT PREV)
> >Cc: users@subversion.tigris.org
> >Subject: Re: Subversion vs Clearcase
> >
> >Chris.Fouts@qimonda.com wrote:
> >> SVN would be my favorite app. only if it had a concept of SCM. If it
> >> does, can someone shed light on it?
> >
> >That might be easier if you explained what you think is
> >missing. You can make branches to isolate work and tags to be
> >able to recall any version by a name. What else do you need?
> >
>
> I really like the power of a configuration spec in CC; is there
> something similar in SVN? Thanks!
For the benefit of people who've never used or seen CC (or whatever
the compared tool du jour is), can folks please briefly explain *what*
a particular feature does, instead of just throwing a name out (if the
name doesn't make it blindingly obvious)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
>-----Original Message-----
>From: Les Mikesell [mailto:lesmikesell@gmail.com]
>Sent: Friday, April 27, 2007 11:45 AM
>To: Fouts Christopher (QNA RTP PT PREV)
>Cc: users@subversion.tigris.org
>Subject: Re: Subversion vs Clearcase
>
>Chris.Fouts@qimonda.com wrote:
>> SVN would be my favorite app. only if it had a concept of SCM. If it
>> does, can someone shed light on it?
>
>That might be easier if you explained what you think is
>missing. You can make branches to isolate work and tags to be
>able to recall any version by a name. What else do you need?
>
I really like the power of a configuration spec in CC; is there
something similar in SVN? Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs Clearcase
Posted by Les Mikesell <le...@gmail.com>.
Chris.Fouts@qimonda.com wrote:
> SVN would be my favorite app. only if it had a concept of SCM. If it does,
> can someone shed light on it?
That might be easier if you explained what you think is missing. You
can make branches to isolate work and tags to be able to recall any
version by a name. What else do you need?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Subversion vs Clearcase
Posted by Ch...@qimonda.com.
SVN would be my favorite app. only if it had a concept of SCM. If it
does,
can someone shed light on it?
After spending considerable effort getting SVN
established at our organization, and hosting very successful multi-site
developments, it appears that a dictat has come down from on high
stating that "Thou shalt use Clearcase".
I've been subscribed to this mailing list for about 5
months, and have noted that a number of organizations are migrating in
the opposite direction i.e ClearCase to Subversion.
I have a strong feeling that we'll be making a huge
mistake by opting for Clearcase, but am looking for some stats to back
this feeling up. Has anyone done any studies in this area? I'd love to
hear from any organizations that have ditched Clearcase...
RE: Subversion vs Clearcase
Posted by Erik Hemdal <er...@comprehensivepower.com>.
HI Steve:
After spending considerable effort getting SVN established at our
organization, and hosting very successful multi-site developments, it
appears that a dictat has come down from on high stating that "Thou shalt
use Clearcase".
I've been subscribed to this mailing list for about 5 months, and have noted
that a number of organizations are migrating in the opposite direction i.e
ClearCase to Subversion.
I have a strong feeling that we'll be making a huge mistake by opting for
Clearcase, but am looking for some stats to back this feeling up. Has anyone
done any studies in this area? I'd love to hear from any organizations that
have ditched Clearcase...
I've used ClearCase in the past, and in some situations, I think it's one of
the best SCM solutions around.
When I used it, I was responsible for CM for 7 teams on three continents who
needed to do concurrent development on the same product. On one occasion,
when a remote repository was completely obliterated by an admin's error,
ClearCase still allowed us to recover completely. And if you have hundreds
of developers, the "heavy" aspects of ClearCase can be of benefit. But it
is very different from Subversion, and supports things that Subversion
doesn't. I'm thinking of the various integrations out of the box, wink-in
builds, views, and the mysterious "versioned object bases" it uses.
It is rock solid, and at some level, you can't go wrong with ClearCase.
It's like the old saying, "No one ever got fired for buying IBM." It's
definitely a top-tier solution.
That being said, I think you'll find it complex, expensive, and heavy. To
be successful with it, I had to spend thousands of dollars on licenses,
training, and equipment to run it. Once your administrator (I'm guessing
that would be you?) knows how to use it, you'll need to spend time training
your users to use it. And you'll spend a fair amount of your time during
each week tweaking, fixing problems, and helping users out of various jams
with the ClearCase-unique features.
Since I had success with ClearCase, I wouldn't say your organization is
making a huge mistake. But it is making a momentous decision. It's not
easy to move away from ClearCase if your process depends on the specific
features it provides.
This is just my opinion; in my current work the niceties of ClearCase aren't
worth the cost, and Subversion fits us well enough. If you can reverse the
decision, then opinions here might help you. If you can't, then explore how
best to move to ClearCase and enjoy the adventure. If there's a ClearCase
user group in your area, attend a meeting or two. I found that most
ClearCase admins are very good with CM in general and can give you good
advice on a migration.
Erik