How to keep track with some reverted old file version in fossil? - version-control

There is a repository repository repo.fossil
bug.c modified many times (eg. revision 10a3->34bd->152c).
There are many files changes in 10a3, 34bd and 152c revision.
Bug will fixed if combine 152c revision with bug.c at 34bd.
How to keep such version, I use following command but failed?
fossil open ~/fs/repo.fossil # contains many files
fossil update -r 34bd bug.c
fossil ci <-- why there is no change?

This seems to be two questions packed into one
1 Why is there no change.
There is no change because you have not made any changes. You have have opened ( copied into the working directory ) the file that belong to "old_revision". You have not changed anything It remains identical to the file for the version as stored in the repository.
2 How to revert a particular file
fossil open ~/fs/repo # contains many files
fossil revert-r <old_revision> one_file
fossil ci
Notice that I am using the revert command, NOT the update command
Here are the details of the revert command http://www.fossil-scm.org/fossil/help?cmd=revert

Related

Is it possible to upload previous changes when using a VCS?

I'm using git as a VCS and I got several commits in a project. I'd like to upload every change made after a specific commit that is not the latest. Currently, if I want to do this, I have to upload practically every file in my project, or manually search for the modified files after a certain date. Both options are kinda tedious.
Is there an option that helps finding the modified files from a certain commit? Or possibly a combination of searching and selecting the files modified in a given range?
Use git log -n 1 --name-only <revision> to get files modified within a specific revision, or git diff --name-only <revision_1> <revision_2> for files that were changed between two particular revisions.

Revert local changes in fossil

How do I clean/revert/undo local, un-commited changes in a single source file with Fossil?
The clean command looks to me like it should do the trick, but no, the local changes are still there. I am looking for the same effect as "git checkout filename.c" would have.
fossil revert <filename>
.
>fossil help revert
Usage: fossil revert ?-r REVISION? ?FILE ...?
Revert to the current repository version of FILE, or to
the version associated with baseline REVISION if the -r flag
appears.
If FILE was part of a rename operation, both the original file
and the renamed file are reverted.
Revert all files if no file name is provided.
If a file is reverted accidently, it can be restored using
the "fossil undo" command.
Options:
-r REVISION revert given FILE(s) back to given REVISION
See also: redo, undo, update

perforce: sync to an earlier revision

I want to test a fix and to compare the behavior before the fix vs. now; I need to sync to a the earlier version. So, if the fix was committed in revision x; how can I sync to one revision before, say x0?
Say that you want to go back to revision 'n' from revison 'n+1' (rollback). You can take the following steps:
p4 sync ...#n
This will sync your files to the older version that you want
p4 edit ...
Open all the files for edit or do "p4 edit filename" to open only a particular file for editing.
p4 sync ...#n+1
Before submiting you need to sync files to the latest revision on the repository.
p4 resolve -ay
This will accept the changes that you have made, ie, revert all the changes done when you moved from revision 'n' to 'n-1'. So effectively, all your files have been rolled back to revision 'n' in your local repository.
p4 submit ...
Go ahead and submit the changes. This will roll back all main repository to revision 'n'. Effectively the revisions 'n' and 'n+2'(current) will be identical.
p4 diff2 -q repository#n repository#n+2
This is just to verify if have rolled back the files. This should show that you have no differing files in the two revisions.
I found the answer while writing my question. I have been trying:
p4 sync ...#x0
where x0 is the changelist before the change containing the fix. But only a fraction of files was getting reverted. I found the issue that when we specify ... only the files in that folder and subfolder(s) get synced. So above command should be executed from the root of the workspace.
If you want to sync a specific version number (not changelist number) for a specific file. This worked for me:
p4 sync //your/depot/path/and/file.name#1
to verify you have the version you want, you can use the have cmd
p4 have //your/depot/path/and/file.name

Replace local file by remote file

How do I replace a local file by its latest version in the repository?
Is there also a way of replacing all local files which are conflicting with the corresponding files from the repository?
Both hg update -C and hg revert will do what you are looking for - replace a locally modified file with the clean version in the repository. Personally I prefer hg revert but hg up -C will also do the job
hg revert
Some further details from the help for hg revert
With no revision specified, revert the specified files or directories to
the contents they had in the parent of the working directory. This
restores the contents of files to an unmodified state and unschedules
adds, removes, copies, and renames. If the working directory has two
parents, you must explicitly specify a revision.
Using the -r/--rev or -d/--date options, revert the given files or
directories to their states as of a specific revision. Because revert does
not change the working directory parents, this will cause these files to
appear modified. This can be helpful to "back out" some or all of an
earlier change. See "hg backout" for a related method.
Modified files are saved with a .orig suffix before reverting. To disable
these backups, use --no-backup.
Hope that helps
Chris
svn update ?
Or delete your folder, and svn checkout...
Or try the option --force.

How can I do a partial update (i.e., get isolated changesets) from subversion with subclipse?

If a file is committed several times with various changes, how can I fetch one change at a time, i.e., one changeset at a time?
I use eclipse, subversion, and subclipse, and I can't change the former two for the time being (or the MS platform..).
In my Team/Synchronization view in eclipse (using subclipse), choosing the changeset model, a file seems to be listed only in the latest relevant changeset even if all changesets are listed. So an earlier changeset doesn't necessarily show the full set of files in the original commit, nor the original diff for a file in a commit.
Update: I'm thinking about using changesets for simplified code review, so I'd like the partial update represented for all the files commited in one changeset. It's easy to get diffs and specific revisions for specific files in eclipse, but I'd like to step through all the changes in one specific commit/ changeset in a practical manner.
As I'm sure you know, svn up will by default grab the latest revision of the file.
However, you can use the -r parameter to svn up to grab a particular revision of a file. So if you know a file was committed in revisions 5, 7, and 9, you could do this:
svn up -r5 myfile
svn up -r7 myfile
svn up -r9 myfile
I believe (but I don't have an installation of it in front of me) that Subclipse has a similar option, labeled something like "Update to Revision..."
Subversion does not support atomic changesets.
(Note: If anyone can prove me wrong, I'll happily switch accepted answer.)
I've compared Git and Subversion using TortoiseGit and TortoiseSVN (and looked at what is possible on the command line).
With both Svn and Git I can update to a certain revision, or see and update to different versions of only one file at a time.
With both Tortoise clients can I see individual commits (revisions) from the repository and look at changes between a revision and the previous revision. (Note that I can't seem to do this in Eclipse, ref the question.)
Only with Git, however, can I update to or cherry-pick an isolated commit. The closest I've seen to this functionality in Subversion is to update to head and then revert a certain revision with a "subtractive merge"...
Test setup: make a project, check out or clone the project, make 2 separate commits to repository from elsewhere, including at least one file that is modified in both commits.
Then, with Git: fetch remote changes.
Then, with both Git and Subversion: look at the log.