Community Tip - Your Friends List is a way to easily have access to the community members that you interact with the most! X
CLI for checkins
si rlog -R --rfilter=daterange:"01.12.2014 00:00:00"-"31.12.2014 00:00:00" --fields=membername,revision,date --noHeaderFormat --noTrailerFormat
Note that the date format here is german and it may be different for your locale.
Also if the "Save Working File Timestamp" option was set on check in the result may not reflect the
check in date.
BTW:
I would find it nice if the "Filter Revision" dialog from the gui
would have some CLI command builder functionality and
support the user for generating si rlog commands resp. options.
HTH Jürgen
Hello Hector Magnanao,
I'd like to emphasize Klaus Thierer's point about the Save Working File Timestamp option: If that was used, that time will be used instead of the default of the time the operation actually occurred.
Hello Klaus Thierer,
That sounds like an excellent Idea, and probably worth posting as one!
Kind Regards to You Both!
-Kael
Hi Klaus,
I have a question regarding this command that you suggested for me.
Klaus Thierer Feb 21, 2017 7:54 AM (in response to Hector Magnanao)
si rlog -R --rfilter=daterange:"01.12.2014 00:00:00"-"31.12.2014 00:00:00" --fields=membername,revision,date --noHeaderFormat --noTrailerFormat
This commands works for me and I was wondering if this command will display all types of changes done to the development path. I mean does it display 'new files added', 'files deleted', 'files renamed', etc...
I would say here that only actions that created new revisions will be reflected and only current members.
(for this example also all development paths will be reflected)
If you change a member name a new revision is generated with an auto comment
"Member renamed from ..."
Unfortunately deleted files or more precisely dropped members can not be catched by this mechanism.
You would have to find further information e.g. based on checkpoints or change packages.
You could try to point si rlog to a specic project revision with --project and --projectrevision then also dropped
members can be reflected but not the members which were added.
BTW:
IMO a decent checkpointing policy is essential when working with Configuration Management only.
For complete tracebilty between checkpoints I can see only change packages having the potential
to close the gap without more or less complex server configuration.
I personally would wish there would be a build in (default) mechanism dor every subproject
which keeps track of all changes to its childs (including set member revision, dropping, labeling?, ...)
since the last checkpoint.
Regards Jürgen
Thanks for your reply Jurgen. So I guess I need to find that CLI that will produce all closed change packages with a date range ? And then I would have to check each action in that change packages to see if it's an add, delete, rename, etc ?
Please advise.
From what understood from SourceCLIReference_Integrity_10_4.pdf until now,
I assume that you will have to parse/filter yourself a lot
and the best you can do is trying to produce parseable output.
For a single change package my approach would be
si viewcp --noheaderformat --notrailerformat --fields=timestamp,type,member,revision,project 123:1 > tab_separated_cp_entries.txt |
tab_separated_cp_entries.txt should be importable with excel wizard, at least if you specify all columns beeing text.
Unfortunately the timestamp field has not a format that you can easily sort in a suitable order.
For closed change packages I would say those having a creation date withing your range are also of interest.
BTW:
Why do you think only closed change packages are of interest?
I'm looking for closed change packages because they are the ones with the checked in files.