A colleague has imported a CVS repository into a pre-existing SVN repository using a cvs2svn dumpfile (like "svnadmin load --parent-dir /path < dumpfile") , which I originally created from the CVS repo.
Now that I'm trying to checkout and build from SVN, I've noticed that some files seem to be missing in the SVN checkout that were present when I checked out the same branch from CVS, although the majority are present. They are mostly but not exclusively binary files (jars and gifs etc.) and I think (though I haven't checked exhaustively) that they are also files that have not been modified on the branch that I'm trying to check out. I should also point out that they don't show up using cvsweb (I would provide a link to the cvsweb documentation but I have no way of knowing its version etc), although they do appear doing a standard checkout of the branch.
If anyone has any idea what's wrong here, or where to start looking to address this, I'd be very grateful! New to SVN so not sure if this is normal! Also, I know I could fairly easily "fix" it by copying over the files but I'd ideally like to keep their revision history so a more complete solution would be preferable. Thanks!
That sounds that the configuration which has been used during the conversion has been wrong. May be a property in svn exists which represent the CVS revision information. If not you're lost..more or less...A good suggestion is to test such migrations and check the contents of the resulting SVN repository...and of course do make backups ...BTW. Are these branches are removed in CVS before?
This is not normal; such files should be handled just fine by cvs2svn. Your best bet is to create a reproducible test case (instructions for doing so are in the cvs2svn FAQ) and report the problem to the cvs2svn users' mailing list.
Related
I have shelved my 26 java files changes via Intellij Idea 2016.2.1 and I checkout to different branch.
When I came to old branch to check my shelved changes.
I gone a mad now, I lost all the files. I was worked nearly two months
Can somebody help to get it back?
You can restore the state of those files if they were edited in IntelliJ. Use local history to see all the changes made in IntelliJ (VCS -> Local History -> Show History).
Even there isn't Shelf tab in IDE you can find shelved changes as patch files at {ProjectName}/.idea/.idea.{ProjectName}/shelf/.idea/shelf.
Then your can apply any selected patch.
I was able to view lost changes and revert back to them by:
right click on project directory, select Local History > Show History
Find the entry in the history menu that you want to restore. You can examine the files by double clicking on the entry and the files to examine differences.
Right click on the entry you want to restore, and select Revert
Note in my case Git>VCS Operations>Show History showed nothing. Only through the Project Files menu.
Andrei's answer was helpful for my situation where I renamed my project and my previously shelved changes were no longer found under the shelf, but I did run into an issue when applying the patch file because I was prompted to "Select missing base" for various files in the patch. Similar to what is seen in the screenshot below:
https://youtrack.jetbrains.com/issue/IDEA-183910
I was able to avoid having to "Select missing base" for various files by first changing the default shelf location and then applying the patch.
https://www.jetbrains.com/help/idea/shelving-and-unshelving-changes.html#change-shelve-location
Also, I found my patch in this location:
{ProjectName}/.idea/shelf
instead of the aforementioned location:
{ProjectName}/.idea/.idea.{ProjectName}/shelf/.idea/shelf
Maybe this will help someone:
I lost part of my shelved changes in combination with an update of IntelliJ. I'm not sure if the update was the reason but eventually most of my most recent (and important) changes were gone.
I couldn't restore them from local history as this does not "survive" an update of IDEA. But in the files I saw that there still is some data:
C:\Users\myUser\AppData\Local\JetBrains\IntelliJIdea2021.2\LocalHistory had a changes.storageData with ~50MB.
Copying the files to the folder of the new version didn't help as the files got overwritten again.
Solution:
I was able to get the old version of IntelliJ (2021.2) here and installed it. This can be done in parallel, without removing the newer version.
Here I was able to retrieve my changes from the Local History and shelve or apply them again.
Hint: Backup the "Local History" folder (or the whole IntelliJIdea20xx.x folder) before you start. I don't remember if I had to copy it in there again or if it worked out of the box. (Just to be sure the local history doesn't get lost).
I've also experienced this bug repeatedly and hence no longer use shelved changes, but rather the Git CLI directly. As of 2022 Jetbrains IDE's still cannot be trusted with their "Smart Checkout" feature, which has a small probability of the total loss of your files (experienced personally in both IntelliJ & Rider).
Unlike another comment here regarding using the Local History, this did not work for me as the history showed nothing. I've also lost many hours of work due to this bug which remains unfixed.
The solution is to use "git stash -u" on the command line, then checkout the desired commit. Once youre done, type "git stash apply" to restore your files. Trusting the "smart checkout" feature is like playing Russian roullette. It's IDE magic that may just fail and you lose everything.
Hello helpful persons,
I'm working with trying to set up some new branch structures in our companies codebase for organization and sanity purposes. True to form decision makers have changed their minds and want the structure to be changed a bit from what I already have in place. Not an over-the-top request though, because no one is yet using the new structure so I have "free reign".
I need to simply move these thousands of files in the containing branch directories (//depot/main/... and //depot/dev/... respectively) into a //depot/main/[product_name]/... structure etc. which I'm on board with and understand the advantages.
While opening the files from //depot/main/... for edit and move I see in my output that there are several warning messages:
warning: edit of deleted file
and
warning: move of deleted file
How can I tell perforce that I do not want to open deleted files for edit, and in turn that I do not want to move deleted files to the new location(s)?
I have a feeling that there is some documentation that I am either not understanding or not finding properly.
Generally you only get that particular warning if you aren't synced to head and are trying to move a file. Make sure you are synced to the head revisions.
As suggested by raven you should probably be using integrate for this. Generally my recommendation is to use 'p4edit/p4 move' intra-branch and 'p4 populate/integ/copy/merge' for interbranch branch integrations.
I have local folder that is branch from formal_versions.
My workflow is:
Mkae changes and than commit them
The integrator merge them in his local branch.
The integrator push its local branch to formal_versions
I use pull to make my local branch identical to formal_versions
This is working fine.
However what should I do in the following scenario:
After pull from formal_versions , I compile the code. As a result , some workspace and obj file are changed (I.E date and time of compilation) and of cource , bazaar explorer inform me on modified files
I again want to make my branch mirror of formal version. What should I do?
A. Why using pull again says that "nothing to pull" even if
I use --overwrite switch ? it is suppose to make my local branch as mirror of the pulled branch...
B. Is my only option is to use revert working tree?
It is generally considered best practice (as well as good for one's sanity) not to version files that are the result of the build process. Executables, shared libraries, and even source files generated from by a 4GL are examples. You can ignore files by using bzr ignore <pattern>, for example bzr ignore *.exe. If the files are already versioned, you will also have to remove them using bzr remove.
bzr pull says there is nothing to pull because the formal version has had no new commits since your last pull.
If you must version the files in question, bzr revert is the only way I know of when bzr pull does not find new revisions. If there had been new revisions in the formal branch, the files should be updated (and will potentially be reported as conflicts).
I'm trying to configure a trac server we are using in my team, in order to avoid an undesired behaviour. We are mainly developing free and open-source software in the team, but we sometimes need to be able to build our early prototypes as completely private.
Because of our first constraint, we want our timeline to be visible for anonymous users. But because of the seconde constraints, we want some commits to be completely hidden from the external world, i.e. we don't want anybody else than us to be able to read the message and content of some commits in the timeline.
Unfortunately, I've been unable to configure Trac the proper way to reach this behaviour untli now. I wan't find a configuration that would let me manage the Timeline content with enough accuracy.
Consequently, I would like to know if such a configuration is possible with trac.
For information, I'm using Trac 0.12.2. The installed plugins are :
Trac 0.12.2
TracAccountManager 0.2.1dev-r7731
TracNav 4.1
The only permission I can see that is related to Timeline is TIMELINE_VIEW.
EDIT :
I have forgot to mention something. We don't want to loose the private commits. And we want them to display for registered users. Consequently, it's not a solution for us to remove them from the database.
EDIT 2 :
Ideally, we would like the commits' message to be displayed according to the right to read the content of our Subversion repository. The idea is that, if a commit is made on a part someone can't access, this person is not supposed to be able to read the message of the commit either.
EDIT 3 :
If we have a look in the configuration file of trac, we already can find :
permission_policies = AuthzSourcePolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
and the authz_file variable is properly set too. Moreover, svn access to the private folders of the svn repositories can't be accessed by anonymous users.
You should set up authz checking for both your Subversion repository and your Trac installation. You can use the same permission file for both. For Subversion, see Path-based authorization in the SVN book. For Trac, enable and configure the trac.versioncontrol.svn_authz.AuthzSourcePolicy component.
This will allow you to have a very fine-grained control over who can access which part of the repository. Note that the implementation of AuthzSourcePolicy in Trac 0.12.2 has a few bugs that will be fixed in 0.12.3.
There are two ways of going about this :
1) You can directly edit the plugins that are running in trac, and add a module that helps you to filter these out at the code level (i.e. you can edit the behavior of the script to , say, only include commits which exclude certain key words). The timeline script is here (trac 2.4) : /usr/local/lib/python2.4/site-packages/trac/Timeline.py (here is an online diff snapshot of the source code : http://trac.edgewall.org/attachment/ticket/890/Timeline.py.diff)
2) You can remove the commits entirely - trac commits are derived from the sqlLite database (the schema is here http://trac.edgewall.org/wiki/TracDev/DatabaseSchema).
Of course, there also might be some fancy tools out there that provide a nice interface for editing the way the timeline looks.
Finally - temporarily, you can remove the timeline/roadmap entirely from the trac.ini file : http://www.gossamer-threads.com/lists/trac/users/28079
I confess that I've virtually no experience with the repository part of Trac, even less with using a repository with a variety of permissions across it's contents.
On the subject: Configuration is certainly not enough, see rblanks answer. While I've never seen the code for that functionality, I was wrong to suggest it doesn't exist. Because it is a central place and developed/supported in Trac core this is definitely the way to go.
I have a drupal site, and I am storing the codebase in a git repository. This seems to be working out well, but I'm also making changes to the database. I'm considering doing periodic dumps of the database and committing to git. I had a few questions about this.
If I overwrite the file, will git think it is a brand new file or will it recognize that it is an altered version of the same file.
Will this potentialy make my repo huge (the database is 16mb)
Can I zip this file? or will this mess Git up ... the zipped version is only 3mb
Any other suggestions?
If you have enough space, a non-compressed dump in source control is pretty handy because you can compare using a diff program what rows were added/modified/deleted.
Another solution is to use the features module which is supposed to capture drupal config in code. It stores this captured data as a feature module which you can put into version control.
For my database applications, I store scripts of DDL statements (like CREATE TABLE) in some sort of version control system. These scripts sometimes include static "seed" data as well. All the version control systems I use are good at recognizing differences in these files, and they are much smaller than the full database with data.
For the dynamically-generated data, I store backups (e.g. from mysqldump) in an appropriate location (depending on the importance of the data, that may include offsite backups).
1) It's all text, so GIT will just see it as it would any other file.
2) No, due to the above it should add 16mb to the repo (or less, due to GITs own compression), it won't add a new file every time, just the changes, so the repo will change by the size of the additions to the repository
3) No, or GIT won't be able to see the differences - GIT does it's own compression anyway