As a slight UI improvement I want to propose to collapse bulky breadcrumbs (highlighted with red rectangles in the picture below) if activities have the same action (push/created/deleted/etc.) and the same target repository. And separate groups of changesets pushed together only by author and timestamp. Unfortunately, it won't help Henry in that case (as shown in Henry's picture), but it could be useful in this case:
Instead of this:
Only show the push info that's different (the author, date and time):
But, honestly, I push several changesets more often, than a single changeset, and so noticeable breadcrumbs help to scan activities easier.
Answer to Henry's follow up question: Obviously, changeset information and push activity information have absolutely different missions. You can extract a lot of useful information from Kiln activities (including push activity). Just several use cases:
- You have strict rules in your company and you allow to your employees to make changes in Kiln only during business hours. Activities help to watch over the employees actions.
- If someone made a commit with wrong author information (wrong entry in local hgrc file), you will always know actual person who pushed changesets to Kiln. The same problem with commit date and time. If someone has wrong date/time settings on his local machine, you will always know at least actual date and time of push.
- Activities allow to see sequence of users actions. If you have only changeset information, obviously, you will able to see only sequence within each repository, but not within the entire Kiln account.
Answer to Henry's Re:followup comment below:
If you want to see when an employee
was working, the datestamp on the
changeset seems much more important
than when it was uploaded;
First, as I said before, if an employee has wrong date/time settings on his local computer, the date/time of the changeset doesn't already seem so important. Moreover, in most cases it doesn't matter when a programmer made a commit, it only makes sense when he shared his work with other programmers (i.e. pushed changeset to Kiln), and when other people can use his contribution.
Second, lets see a bit deeper. Probably, if your company has strict rules about working with source code management system, it has some reasons. For example, every day, after business hours, an administrator makes a backup copy of Kiln database. So, you have to keep the database with source code for each day. That's why it could be useful to know if someone makes changes, when it's not allowed.
Identifying incorrect settings is a
noble goal, but hardly seems worth all
What effort do you mean?! Kiln does all the things automatically.
Even now, the push activities are
clumped by repo... by definition you
push to a repo, not to the account.
Showing just the changesets for each
repo would still have all the
Activities provide information across all projects and repositories. If you work with only one particular repository, maybe other information isn't important for you, but if you need to get know about the work of other employees, it's extremely inconvenient to look into each repository.