On 10/18/07, Kern Sibbald <[EMAIL PROTECTED]> wrote: > On Thursday 18 October 2007 22:54, Michael Short wrote: > > On 10/18/07, Kern Sibbald <[EMAIL PROTECTED]> wrote: [...] > > > If you create any new files, you must explicitly tell me, or they will > > > not be added to the SVN. No, the above command that you provide will > > > definitely not work. > > > > Right, sorry. > > Nothing to be sorry about. It is something new. It is really rare that > someone sends me a patch with new files -- it was logical in this case > because they correspond to the new tests that have been added over the last 6 > months. I'm as guilty as you.
A nice solution to this problem is to have a manifest file included as part of the bundle. This file lists every file that is part of the raw source code. When patches add, remove or rename files then this file also will need to be patched, making it very obvious that such a change has occurred. This file can also be useful for many things, such as a description of the purpose of every file, or things like cleanup, as its easy to write a script that will remove all files from the source tree that arent listed in the manifest. It can also be useful for things like test procedures which can open the file and scan it for files that are marked as being test files. Similarly it would be easy to write a script that takes all and only the files in the manifest and produces a non SVN targ.gz containing its contentswhich is useful for releasing static snapshots of named releases without requiring SVN access to the source tree. (Not everybody develops or compiles online, and in some scenarios they flat out cant -- such as in secure environments). Another nice advantage of the MANIFEST file is that doing an annotate on the file will quickly show the revisions where every file was added. In the Perl distribution this file is called MANIFEST, is located in the root directory of the project and is of a simple format. Relatively qualified path and filename, tab, comment about what the file is for. In perl all test files are named .t so the Perl test frameworks can just scan this file to find all the test files. As an example of the utility of this approach It was trivial when I needed the ability to test a subset of Perls functionality to write a filter that allowed our test scripts to scan the file list and look for tests that matched a regex. Here is a link to an annotated version of the Perl manifest file. List readers please dont follow the link unless it really is relevent to you. Rendering this can take some time and puts a fair amount of load on the server that provides it. http://public.activestate.com/cgi-bin/perlbrowse/b/MANIFEST I also suggest that if you havent done it already set up your SVN repo with a commit hook to create a .patch file which contains the latest revision number. That way it is trivial to identify which revision a patch is made against, with or without SVN access. cheers, Yves ps: Sorry I havent been able to contribute anything lately, my supply of round tuits has been extremely lacking. But im hopeful that sometime in the new year I will be able to put some efforts into Bacula once again. -- perl -Mre=debug -e "/just|another|perl|hacker/" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
