I'm not particularly experienced with ClearCase, so if my terminology is incorrect please let me know.
In Git I can run the command:
git archive -o /tmp/dump.zip $SHA_FROM_THE_PAST path/to/dump
I want to do something similar in ClearCase.
The ClearCase repository contains two branches: main and snapshot_foo.
snapshot_foo branches from main at some point in the past.
What I want is a dump of all the files as they looked at the time the snapshot was first created.
I understand that there is no 'global' state identifier like there is in Git; in AFAIK, in ClearCase each element is versioned individually, so there will not necessarily be a one-to-one equivalent to that command.
I've thought about creating a new snapshot starting at the same point in time from main, and just copying what I need from that, but I am bewildered and confused as to how I would go about it.
The simplest case would be when you have set a label on main just before creating snapshot.
But if you have no such label, you can get all the files at the time just before the creation of the snapshot_foo branch:
a/ cleartool descr -l brtype:snapshot_foo#/myVob to get the date of creation for this branch
b/ make a snapshot view with a time-based selection rule similar to this question
element /myPath/... /main/{!created_since(01-Sep-2008.12:34:56)}
element /myPath/... /main/LATEST
(with 12h 34 minutes 56 seconds being the time just before the creation of the brtype snapshot_foo)
(see the config_spec man page)
Once the snapshot view is created with the right versions in it, you can zip its content, achieving a similar result to the git archive you mention in your question.
Related
In Pijul how can I see what happened in a patch?
I'm looking for something similar to git diff <commit> <commit>^.
I tried pijul diff but it seems to only work with branches. And I couldn't get pijul log to show any details of patches, either.
I suspect what I'm looking for is possible because clicking a patch in Nest shows a diff and there is patch pretty-printing in libpijul which includes a change list.
I believe you are looking for pijul change ⟨patch-hash⟩
Edit: patch is now called change
I don't see how to do this with current pijul?
pijul 1.0.0-beta.2
Pierre-Étienne Meunier <pe#pijul.org>
USAGE:
pijul <SUBCOMMAND>
OPTIONS:
-h, --help Print help information
-V, --version Print version information
SUBCOMMANDS:
add Adds a path to the tree
apply Applies changes to a channel
archive Creates an archive of the repository
change Shows information about a particular change
channel Manages different channels
clone Clones an existing pijul repository
credit Shows which change last affected each line of the given file(s)
debug
diff Shows difference between two channels/changes
fork Create a new channel
help Print this message or the help of the given subcommand(s)
init Initializes an empty pijul repository
key Key generation and management
list Lists files tracked by pijul
log Show the entire log of changes
move Moves a file in the working copy and the tree
pull Pulls changes from a remote upstream
push Pushes changes to a remote upstream
record Creates a new change
remote Manages remote repositories
remove Removes a file from the tree of tracked files (`pijul record` will then record
this as a deletion)
reset Resets the working copy to the last recorded change
tag Manage tags (create tags, check out a tag)
unrecord Unrecords a list of changes
In IBM Clearcase, I am trying to find the view name which was used to create a version on a branch. If I do version properties / Element properties I get information onto who created it but not the view name used to create that particular version.
Is there a quick cmd-prmpt way to find out which view was used on a particular version of a branch.
You can see the view name of a checked-out version.
But not directly of a checked-in one.
Check the result of a cleartool lshist -minor and see if the event you see (checkin, described in events_ccase ) does include the view used to make the checkin.
Try it on the file:
cleartool lshist -minor aFile
Or on the branch:
cleartool lshistory -minor -branch rel2_bugfix
I don't think cleartool descr -l would help directly.
As a last resort, check-out "Identifying elements by the source container path"
You cannot see the name of the view used to create a checked-in version. If you feel the information is critical to retain, you can create a postop checkin trigger to append the view information to the checkin comment using cleartool chevent.
I think you may be "thinking git" where it may be critical to know which "remote" was used to create a commit.
In CC, after a checkin, the view private data/metadata associated with the checkout is removed from the view and VOB. What is the objective of retaining that information?
As in not only the major changes maybe the installed dependencies and all before a release without checking one by one?
Since Git won't know which commits are important to you, you'll have to first define your own set of guidelines/format on how you write your commit messages, which you can then use later on to easily differentiate all the commits made for a particular development period.
For example:
If it's a bug fix, prepend the commit message with a "[bugfix]"
If it's a new feature, prepend the commit message with a "[feature]"
If it's a project setup change, prepend the commit message with a "[migration]"
Then, once all the branches have been merged to the main branch (let's say it's develop), checkout the develop branch and use git log --grep=<PATTERN> to identify a specific set of commits.
For example, if you only need the bug fix commits, do a:
git log --grep="bugfix"
which will show you all the commits with "bugfix" in the commit message.
If you only need the commits for a specific period, you can use the --since=<date> option:
git log --since="2017-06-01" --grep="bugfix"
If you want a formatted list (something that you can easily output to some sort of release notes, I assume), you can use the --format=<format> option:
git log --since="2017-06-01" --grep="bugfix" --format="(%ci) %h : %s"
The command above will give you something like this:
(2017-06-18 18:26:36 +0800) 63f330f : [bugfix] prevent crash when dialog is sent to background
(2017-07-01 10:03:40 +0800) cdcbd91 : [bugfix] remove extra row at the end of the list
You can check out the other format options from the complete git log docs.
Basically, it will all depend on your commit message format.
As a tip, you can look into using a commit.template to make it easier to format your commit messages.
commit.template
If you set this to the path of a file on your system,
Git will use that file as the default message when you commit. For
instance, suppose you create a template file at ~/.gitmessage.txt that
looks like this:
subject line
what happened
[ticket: X]
We've set up our own Mercurial workflow which works great for us. However I'm wondering about something: is it possible to create some "junk" repository that would basically be a place where every user could always "push -f" their changesets and where we'd never do anything besides "push -f"?
That is: the goal of that repository would not be to integrate/merge/pull. Actually it would not be part of our workflow. It would really just be a "place to backup all the changesets".
The only moment we'd retrieve a changeset from it is if a user got a hard disk crash or a theft and had changesets that he "pushed -f" to this hypotethic "changeset backup" repo but not to the repository(ies) part of our real workflow (there'd be plenty of reason why this would happen: one of them being that keeping an always accessible "unverified" junk repository always available would be very easy).
I just did a test with three users doing "push -f" and now it looks like the following (note that the parent of the working directory stays at the very bottom, at changeset 0, and would forever stays there):
$ hg glo | grep -v user: | grep -v date
o changeset: 3:4337a665659f
| tag: tip
| parent: 0:ab3e3171d569
| summary: 1st change by user B
|
| o changeset: 2:2349e3eed60d
|/ parent: 0:ab3e3171d569
| summary: 1st change by user C
|
| o changeset: 1:10405f5e0994
|/ summary: 1st change by user A
|
# changeset: 0:ab3e3171d569
summary: Init
Would this keep working once users starts pulling from other repositories, merging their work, etc.?
In other words it would be a repositories where resolving merging issues wouldn't be a concern and where "push -f" and creating new heads would be very welcome and where the working directory's parent would always stays at "changeset 0". It's only goal would be to serve as "changesets backup" folder (for example to backup changesets that haven't been integrated yet in our real workflow).
Would this work and does this make any sense?
(note that should this not make any sense wouldn't make the question less interesting, other people may want to do exactly this and then may want to find why it wouldn't make sense)
Yes, it would work just fine. Your 'junk' repository would just end up with a ton of heads.
You can use hg pull -r to retrieve a particular changeset (and all of its ancestors) from the junk repository, so you won't have to worry about ever having to merge together all that cruft.
Now, keeping track of which changeset is which, and which one you want to pull in order to restore something you've lost is a harder question. You can look at the tree, but that tree is going to get complicated and bushy with lots of heads. It can still be done of course, it's just not necessarily trivial.
If you use some of the hooks to keep a log of when changesets were pushed and where they were pushed from, that should help you find the one you want when it comes time to recover things.
The usefulness of any backup method can only be measured by the ability to restore. In this case, I don't think you'd have an efficient restore route.
Apologies if this isn't the answer you're after since you've already a workflow in place, but another way to handle backups is by having each developer clone the 'main' repository on the (presumably backed-up) server and then pulling from that clone. They then push back to 'their' clone on the server as often as they want and only promote the changesets to the main repository as required.
This will get the changesets on a central server somewhere and make the restore more straightforward as each developer's changesets are isolated.
The other option I'm sure you've considered is a separate backup process for local developer's PCs. Perhaps something automated and in the background like Carbonite?
Hope this helps.
Generally,our fixes/patches for any bugs involves changes in multiple files and we will commit all these files in a single shot.
In SVN, for each commit (may involve multiple files),it will increment revision number of whole repository by one. So, we can easily link all the multiple files that went in a single commit.
Now the difficulty with the same case in CVS is that it will increment the revision numbers of all the files individually. Let's say if a commit involves the following files:
file1.c //revision assigned as part of this commit..1.5.10.2
file2.c //revision assigned as part of this commit..1.41.10.1
and the comment given for this commit is "First Bug Fix".
Now, the only way to get all files checked-in as part of this commit is by searching through all the cvs logs for comment "First Bug Fix" and hopefully it will return only the two file revisions mentioned above.
Please share your views on if there is any better way in CVS to keep track of all files checked-in in a single commit instead of relaying on comment given as part of commit.
I think CVSps might do what you are looking for.
"CVSps is a program for generating 'patchset' information from a CVS repository. A patchset in this case is defined as a set of changes made to a collection of files, and all committed at the same time (using a single 'cvs commit' command). This information is valuable to seeing the big picture of the evolution of a cvs project. While cvs tracks revision information, it is often difficult to see what changes were committed 'atomically' to the repository."
This cvsps relies on cvs client. Make sure you have proper version of cvs which supports rlog command (1.1.1)
CVS does not have inherent support for "transactions".
You need some additional glue to do this. Fortunately, this has all been done for you and is available in a very nice extension called "cvszilla".
The home page is here:
http://www.nyetwork.org/wiki/CVSZilla
This also ties in to CVSweb, which is a great way to browse through your CVS modules via a web-based GUI.
Perhaps the ANT CvsChangeLog Task is another choice. See http://ant.apache.org/manual/Tasks/changelog.html . It provides date and time for a checkin message. You can produce nice reports with XSLT - try the example at the bottom of the ANT manual page.
I know it's late for an answer, but perhaps other users come across this like I did (searching) and appreciate the ANT integration.
OK, I just installed cvsps and ran it from the top level. Here's a sample of the output... this is one of the few hundred patch sets on my module. Note that indeed this does work across different directory trees.
---------------------
PatchSet 221
Date: 2009/04/22 22:09:37
Author: jlove-ext
Branch: HEAD
Tag: LCA_v1_0_0_0_v6
Log:
Bug: 45562
Check the length of strings in messages. Namely:
* Logical server IDs cannot be more than 18 characters (forcing a
TCSE protocol requirement).
* Overall 'sid' (filter) search string length cannot be more than
500 (this is actually more than the technical maximum messages are
allowed, but is close).
Alarm messages and are now not going to crash either as the alarm text
is shortened if necessary by the LCA.
Members:
catalogue/extractCmnAlarms.pl:1.2->1.3
programs/ldapControlAgent/LcaCommon.h:1.18->1.19
programs/ldapControlAgent/LcaUtils.cc:1.20->1.21
programs/ldapControlAgent/LcaUtils.h:1.6->1.7
programs/ldapControlAgent/LdapSession.cc:1.61->1.62
tests/cts-45562.txt:INITIAL->1.1
So, this may indeed do what you want. Nice one, Joakim. However, as mentioned, CVSzilla does much more than this:
Web-browsable CVS repositories (via CVSweb).
Web-browsable transactions.
Supports transactions across modules.
Generates CVS commands (using 'cvs -j') to merge patchsets onto other branches.
Integration with bugzilla (transactions are automatically registered against bugs).
If all you want is just the patchset info, go with cvsps. If you're looking to use CVS on large projects over a long period of time and are thinking about using bugzilla for your bug-tracking, then I would suggest looking into CVSzilla.
This also could be useful:
http://code.google.com/a/eclipselabs.org/p/changelog/