It seems to me maven-resources-plugin copy-resource couldn't overwrite read-only files.
The file is read-only because our svn require an "lock" to make it read-write.
It doesn't work if i added "<overwrite>true</overwrite>" (I understand this is not for this purpose).
Working with locks in relationship with SVN and source code does not make sense. And of course the maven-resources-plugin does not support this misuse. The simple answer to this question is: Don't use locks on source files.
Related
I want to remove untracked files from the working tree. Like here
https://www.kernel.org/pub/software/scm/git/docs/git-clean.html
libgit2 doesn't implement this itself. It's a porcelain command, which deals with interaction with the user. It also deals primarily with files which are of no interest to the Git repository.
You can run status to see which files are untracked and then remove whichever ones the version of git-clean would have removed through the usual means available in your programming language.
I try to write a file store based on libgit2.
Software snapshots should be saved as branches mysoftware and specific versions committed and tagged. Then later I want to checkout the tags to different directories.
When looking at git_checkout_tree, it seems like there is only one working tree for a repository and thus it does not even seem possible to checkout multiple working trees concurrently.
Is this correct!?
EDIT:
Additionally, I would like for this thing to work on Windows without the need for cygwin!
The git_checkout_opts structure in libgit2 contains a target_directory option that will allow git_checkout_tree() to write to a different directory instead of using the default working tree for the repository. This would allow you to custom build a solution with libgit2 that maintained multiple checked out copies.
Without using that option, a libgit2 git_repository object expects there will be just one working directory and looks to the core.worktree config option if it isn't the "natural" working directory for the repository.
The git-new-workdir tricks with symlinks in the .git directory don't work great with libgit2 right now, I'm afraid, and particularly doesn't work well on Windows. I'd love to see this addressed, but it isn't too high on my priority list.
Git doesn't support this natively, but you can use git-new-workdir to do it.
so yeah just wondering if darcs has anything equivalent to git's submodules.
i.e. lets say I have a repo (myapp) and I have a folder in it called mylibrary. mylibrary doesn't really have anything to do with myapp's development, it just has to be included. mylibrary's development happens in it's own repo, but when someone pulls myapp, it'll also pull an up-to-date version of mylibrary. any ideas?
My first thought: Since darcs is simpler than git (i.e., no branches and remotes--instead you just use directories and URLs, and it's your task to manage them), a darcs submodule would not give much more than what you can achieve with standard things like subdirectories or files inside you darcs repo.
If you needed a submodule in order to fix a certain state of the source of the used library, you could perhaps simply put a copy of the library's repo as a subdir and add it to your project's darcs. Compared to git, this would have the disadvantage of bloating the data transfer when someone gets your repo.
If you needed a submodule to tell those who get your repo where to get the updated source of the library (without bloating the size of your repo), you could simply put an URL and an instruction into a README file, or a script, or whatever. Compared to git, the disadvantage is that the state of the library's source as it was when you used it wouldn't be recorded in your commit, so people might get another version of the library, and the compilation wouldn't succeed, and it wouldn't be clear why.
So, the really interesting goal of a submodule could be not just to tell people where to get the library source from (as you write in the question), but to record the state of the subproject that you have actually used for compiling your project, and not to bloat your repo for those who don't want to get the source of the subproject.
Probably, this goal could also be achieved by storing more complex metadata about the state of the subproject, and a more complex hook to get exactly that state (or--by choice--another state) of the subproject. AFAIK from the docs, there is no built-in mechanism for such submodules.
Update (found on the darcs site):
http://darcs.net/Ideas/Subrepositories;
http://darcs.net/Ideas/NestedRepositories.
So, darcs will notice another darcs repo inside your working and it won't touch it. So the first way I've suggested above is shut (if you leave the darcs metadata there).
The second way is like something suggested in one of the section of the latter link. (They suggest an "uglu" script for something like this.)
Another (3rd) idea
Import the patches from the repo you intend to have as a submodule, but first move all files into a subdir. If it were possible just to apply such a moving special patch once and if it was effective for all the patches you import from the repo intended as submodule, but not to the patches you import from a "branch" of the main repo...
...well, it could be a special variant of the pull command (say, import) and of the push command (say, export) that would additionaly translate the paths accordingly.
I don't know of any submodule concept for darcs, which means the usual way to refer to another (shared) repo from a darcs repo would be through symlinks.
Since symlinks aren't supported with darcs, that means you needs to put in place a "posthook sh update-symlinks.sh" hook script to restore those links.
But you could also use add to this hook a check to see first what version of the lined repo is currently loaded, and update that version if needed (provided you have store in one way or another the exact version you need for that shared repo).
That last suggestion is actually close to the implementation of Git submodules or Mercurial subrepos.
I was wondering if I right click on a file in the SVN repo browser, does it get permanently deleted? can it be recovered?
This question/answer from the SVN FAQ might interest you :
How do I completely remove a file from the repository's history?
There are special cases where you
might want to destroy all evidence of
a file or commit. (Perhaps somebody
accidentally committed a confidential
document.) This isn't so easy, because
Subversion is deliberately designed to
never lose information. Revisions are
immutable trees which build upon one
another. Removing a revision from
history would cause a domino effect,
creating chaos in all subsequent
revisions and possibly invalidating
all working copies.
The project has plans, however, to
someday implement an svnadmin obliterate command which would
accomplish the task of permanently
deleting information. (See issue 516.)
In the meantime, your only recourse is
to svnadmin dump your repository, then
pipe the dumpfile through
svndumpfilter (excluding the bad path)
into an svnadmin load command.
If it's that hard, there are little chances it can be done easily from Tortoise SVN...
(And it's not the goal of Source Control...)
You'll find that you can only delete from the Repo Browser when you are viewing the HEAD revision. This is identical to deleting a file from your working copy and then checking in the delete. In both cases, you'll be able to restore from the previous revision.
Deleting a file via the repo-browser context menu basically creates a new global revision where just that file was deleted, so it appears in the log as such - you can always revert to that revision to get the file back, or you can just pull it directly from the repository into your working copy.
No... Deleting a file (even using the repo browser) only affects working copies. It would be a pretty lousy revision control system if you couldn't recover a file from the past. It is actually pretty difficult to modify files in a committed revision, even if you have root access to the server.
Doesn't right-click just bring up some sort of menu? And with SVN is that you can always revert anyways.
I deleted a top level directory from Repo Browser by accident and the only way to get it back was the following:
Export the top level folder from a previous version history
Make a new folder in the repository to replace the one deleted.
Add the exported files back to the new directory (same name as previous)
Update the working copy, it will delete and then re-add the same files.
Its annoying but at least the working and repo will be back in sync. The "Revert Changes from this Revision" didnt work for undoing repo deletes, it only reverts in working directory not the "Undo" the delete to the repository.
I have a project where I create a JAR which contains a bunch of classes with main() plus a set of scripts which set the environment to invoke them. Most of those are long running processes which log a lot (~10-20GB).
This means I have a pretty complex log4j.xml file which, being in src/main/resources/, goes into the JAR. When something breaks in the production system, I'd like to modify the logging on the fly for a single run.
So I came up with the idea to have a conf/ directory on the production and put that into the classpath, first. Then, I thought that it would be great if M2 would put the config files in there (instead of the JAR). But that would overwrite any manual changes during an automated deployment which I strongly dislike. I'm also not fond of timestamps and things like that.
So my next ideas was this: M2 should leave the config files in the JAR but create copies of the files with the name *.tpl in the conf/ directory. The admin could then copy a template to the basename to override the files in the JARs. .tpl-Files would be overwritten but that wouldn't hurt. Admins would have full control over which version of the log was active and they could run a diff to see whether any important changes were made.
Now the question: Has someone seen a plugin which automates this process? That is which creates a conf/ directory with all or a selected subset of everything in src/main/resources/ and which renames the files?
Best practice in Maven handling config files is to place them in a separate conf directory, and pack them in a binary assembly using the assembly plugin. Placing configuration files, like log4j.xml in the src/main/resources doesn't make sense, since it is not a true application resource, but more of a configuration file.
We cope with the overwriting, by packing the configuration files with the posfix .def. For example: myapp.properties is packed into the assembly as myapp.properties.def. When the person who uses the assembly unpacks it, it will not overwrite his original files. After unpacking he simply merges them by an external tool (we use meld in Fedora Core).
I may be missing something and this doesn't answer directly the question but did you consider producing a zip assembly of the exploded content of required artifacts (to be unzipped on the target environment)?
Sounds like you're attacking the problem the wrong way. Why not just run the application with -Dlog4j.configuration=/some/where/my-log4j.properties? If you want, you can add a command line flag to main() which invokes the PropertyConfigurator directly.