How to get stream history via CLI?

'scm history' will only show the history of individual components.

If you want to get a listing of the changes between two points in time (as your svn-ese suggests) then you should look into creating snapshots at those points in time and using 'scm compare' to get a full listing of changes.

that's unfortunate. RTC is already far too 'concept heavy' in my opinion and introducing yet another one (snapshots) into the mix for doing something so fundamental as getting a commit history is yet another layer of complexity I wish wasn't there.

is there at least a way i can query which components are part of a stream so that i can simply loop through the list to achieve what i want?

i do not want to deal with snapshots to be honest, i already find that some other limitations of the tool (like not being able to link more than one client at a time to a workspace without strange things happening) to be very cumbersome. the workaround (having multiple workspaces, one per machine) has led to a large collection of workspaces that are confusing to manage since i often develop from many different machines on a cluster.

RTC is already far too 'concept heavy' in my opinion and introducing yet another one (snapshots) into the mix for doing something so fundamental as getting a commit history is yet another layer of complexity I wish wasn't there.

When I started working on RTC, I found the profusion of concepts confusing. But after messing around with the tool, they started to make sense. Some of the ideas (like remote workspaces, components and snapshots) make my job easier.

If you're having a hard time with the concept of a snapshot, think of it as a tag in (ahem) other version control systems. It's light weight (in that it can be created easily), and it can be flowed between streams.

is there at least a way i can query which components are part of a stream so that i can simply loop through the list to achieve what i want?

Try 'scm help list components'.

I don't recommend that strategy, however. 'scm compare' is designed specifically for creating change logs and can give you lots of useful information that would be hard to derive by looping over components.

i do not want to deal with snapshots to be honest, i already find that some other limitations of the tool (like not being able to link more than one client at a time to a workspace without strange things happening) to be very cumbersome.

If you're having difficulties you should raise bugs. We can't fix problems if we don't know they are there.

First, thanks for the reply. I know I can sound peevish sometimes, I don't mean to be.

I don't think any of the items I mentioned are 'bugs' per se. They seem to be part of the design, I will file this under a feature request.

The unfortunate thing about the 'snapshot' notion (which maps back to tags in SVN/CVS as far I can tell) is that it relies on the good graces of a developer to manually create one. The really nice thing about SVN was that each commit was atomic and associated with a unique integer identifier so 'snapshots" in that sense were automatic. In fact, a main motivation of that notion was because tags failed so miserably in CVS. I'm sometimes in the situation where I want to see all changes that went on *everywhere* in the repository regardless of whether other developers have had the good sense to create a snapshot. I think that's a common need (especially in a crisis when you're trying to track down a bug introduced in a release). With RTC, I don't see a simple way of asking ("what were all the changes in my streams in the last N days, regardless of who did them?")

The tool really needs a simple way of doing this without running into walls associated with Rational's philosophy of how SCM should go on. At the most basic level, we're dealing with the evolution of code artifacts via a series of deltas. There should be a way of getting all deltas in a project since bugs often occur in unexpected places and are introduced by newer developers who often are particularly naive about conforming to rigorous SCM practices.

I don't think any of the items I mentioned are 'bugs' per se. They seem to be part of the design, I will file this under a feature request.

That's still helpful. Work items are our only real feedback about user frustrations.

I'm sometimes in the situation where I want to see all changes that went on *everywhere* in the repository regardless of whether other developers have had the good sense to create a snapshot. I think that's a common need (especially in a crisis when you're trying to track down a bug introduced in a release). With RTC, I don't see a simple way of asking ("what were all the changes in my streams in the last N days, regardless of who did them?")

When you say you want to see the changes everywhere, do you really mean that? It's possible that other contributors have created change sets that haven't been delivered to a stream you collaborate with. If you want to see those, you'll have to use the Eclipse UI.

But that's a different use case than you originally suggested.

The tool really needs a simple way of doing this without running into walls associated with Rational's philosophy of how SCM should go on. At the most basic level, we're dealing with the evolution of code artifacts via a series of deltas. There should be a way of getting all deltas in a project since bugs often occur in unexpected places and are introduced by newer developers who often are particularly naive about conforming to rigorous SCM practices.

Wouldn't your builds pick that up? Since builds automatically create snapshots, you can use 'scm compare' to narrow the set of offending changes.

Can you expand on your use case? You've told us that you want to see what has happened between two points of time, but you haven't said what you are going to use that information for.

Minimally I'd like to see all deltas *delivered* to a stream between any two points in time. Remember that not everyone using the tool is going to take the time to use its formal build process (and thus get a snapshot.) For example, on another project we use command line based build method (scons) for manging compiles and packaging components in archives that get delivered on some regular basis. There's a lot of time and effort put into that entire infrastructure which we don't want to redo. If I delivered releases to the customer on Jan 1 and Feb 1 respectively and they tell me that something is broken in the Feb 1 release that worked fine in the Jan 1 release , I would typically do:

svn log -r{Jan1:Feb1} to see who touched what over that period of time and then start zooming into the changes via
svn diff -r{Jan1:Feb1}

also, regarding builds, for teams that are not even at the stage of making formal releases it's still useful to be able to figure out what happened recently to the main trunk of development (the repository workspace i guess) all in one shot without having to go through the complexity of worrying about workspaces.

I can't comment on your process, but I would expect that you would want to make a snapshot when you deliver a build to your client. Dates don't have fine enough granularity to ensure that all of the changes are included (ie, what happens if there are deliveries during the day that you make your release - which ones do you include in your comparison?).

Since you're using an automated build, you should create the snapshots there. Even ignoring your comparison scenario, snapshots aid in reproducibility.

If you really want to compare based on dates (which seems like a legit use case to me), you should submit a feature request.

I will post this a feature request.

Regarding your comment about dates not being fine grained enough, that's true but they are often sufficient when you happen to know the time down to the second (as we do after we post our release archive). Additionally, with svn you really don't have to worry about dates, you would just use the revision number of the repository which is unambiguous. I've been using dates in our discussion because I was assuming that's an easier concept for RTC since i'm sure that's tracked somewhere whereas the notion of a repository revision number (a la SVN) might not be.

The fact that this concept is common across a host of other SCM systems says (to me anyway) that it's probably something most people want (if not necessary a good thing to have.) See the examples section of http://www.kernel.org/pub/software/scm/git/docs/git-log.html, something like:

git log --since="2 weeks ago" -- gitk

Would be very helpful. Perhaps you can put such a proposal to your user base to see if there's general interest in it. I can't imagine that I'm far from the mainstream on this but I'd be interested in knowing if I was.

Remember that not everyone using the tool is going to take the time to use its formal build process (and thus get a snapshot.)

Very interesting discussion. Don't want to break the thread but just in case it was not clear, builds create snapshots (so you can always go back to the original source for any build), but you can create a snapshot at any time you like (it's a single command from the commandline or a mouse click or two in an IDE). Again - apologies if this was clear already.

anthony

It was clear, thanks. My only concern with the snapshot concept is that it requires that either one be be created manually (you can't always be sure people will) or that a formal build is generated (so that it's created as part of that.) I can think of many instances where those two things won't happen but yet I still want to track all changes over some defined time period. Years ago we tried to track commit points with CVS tags and it was a disaster (precisely because they were somewhat arbitrary and we ended up with 100s of them that soon became meaningless.) In that way, the SVN concept of an atomic commit with a well-defined repository state (defined by an integer) was a god send.