This is something I've never really understood about source control, specifically Subversion (the only source control I've ever used, which isn't saying much). I'm considering moving to git or Mercurial, so if that affects the answer to my question, please indicate as such.
Ok. As I understand it, every time I create a new file, I have to tell SVN about it, so that it knows to add it to the repository and place it under control. Something like:
svn add newfile
That's fine if I'm the one creating the file: I know I created it, I know its name, I know where it lives, so it's easy to tell SVN about it.
But now suppose I'm using a framework of some kind, like Rails, Django, Symfony, etc., and suppose I've already done the initial commit. All of these frameworks create new files programmatically, often many at once, in different directories, etc. etc. How do I tell the source control about these new files? Do I have to hunt each one of them down individually and add them? Is there an easier way? (Or am I possibly misunderstanding something fundamental about source control?)
Generally speaking, you shouldn't add files to source control if they can be generated from other files in your project. It's true that in some cases, a file is initially generated, but must be modified manually. In that case you will have to add it to source control. However, you should almost never automatically add files.
I agree with Matthew in general, if it can be generated it shouldn't be added but remain dynamically created.
For the practical question of adding multiple files, I don't remember in svn (though I think it should be possible), but to do this in git:
Using git bash (command line) you can add all "loose" files under the directory or subdirectory by not specifying a file after the add command. You can also set git to ignore certain files, so they wont be added in that case.
Another way is using git gui, it displays all un-tracked files and you can select them all (or groups of it) and add them in one click.
Related
Requirement
make history for web text/code source files.
login-worker is only me, i.e personal usage.
automatically save history for each updated files(no require at once but at least once per week)
It must be a simple way to start and work.
I have 3 work places so need to do async files.
(not must but hopefully for future working environment) Any other non-engineer can also understand the location of history file and can see it easily.
Current way:
I made history folder the day, download files in there for edit, copy files when I edit/creat new one.
Advantage of the current way:
Very quick and simple, no need to do additional task to make history
Disadvantage of the current way:
Messy. Whenever day I work, I create a new history folder to keep downloaded files, so that it is messy in Finder(or windows explore).
Also, I don't have a way to Doing Async files for sure with in other places.
I tested to use GIT before, I had Thought GIT automatically save files I edit and save with a editor, but that was not the case. Also GIT is too complicated to use/start. If you recommend GIT, you need to show me ways to deal with the problem I had, for instance, simple GIT GUI with limited options without merging/project/branch etc because of personal usage for maintaining just one website.
Do you know any way to do version control personally and simply?
Thanks.
Suppose you entered <form ...> in your HTML—without the closing tag—and saved the file; do you really think the commit created by our imaginary VCS picked up that file's update event would have any sense?
What I mean, is that as with writing programs¹,
the history of source code changes are there for humans to read,
and for that matter, a good history graph should really read like a prose:
each commit should be atomic in the sense it comprises one (small) but
internally integral feature or fixes a bug, and had to be properly annotated
so that the intent of the change captured by that commit is clear.
What you want instead is just some dumb stream of changes purely for backup purposes.
Well, if you're fully aware of the repercussions (the most glaring one is that the generated history is completely useless for doing development on
the project and can only be used for rollbacks in case of "oopsies"),
there are two ways to go:
Some IDEs (namely, Eclipse) save a backup copy of each file they manage
on each save—thus providing your with such a rollback functionality w/o
using any VCS.
Script around any VCS you like: say, on Linux,
you start something like inotifywait telling it to watch your
project's root directory, recurvively, for write events on files,
read whatever the tool prints to its stdout when these events happen,
and for each event, call to your VCS of choice to record a new commit
with these changes.
¹ «Programs must be written for people to read, and only incidentally for machines to execute.» — Abelson & Sussman, "Structure and Interpretation of Computer Programs", preface to the first edition.
I strongly suggest you to have a deeper look at git.
It may looks difficult at the beginning, but you should spend some time learning it, that's all. All the problems above could be easily solved if you spend some time to learn the basics. There is also a nice "tutorial" on github on how to use git, no need to install anything: https://try.github.io/levels/1/challenges/1.
I know about templates. I know this has been asked before (here and here). Please let me explain my situation in detail and hopefully you'll understand why I'm asking this question again.
I use an IDE (and language) called PowerBuilder. PowerBuilder (PB) stores source code and binary object code together in a PBL (pibble) file. A PBL can contain source code for multiple classes. Because of this, it's not really practical to keep the PBL under version control; it's each individual class that should be revisioned independently. However, since it's the PBL file itself that the IDE uses, and because of the presence of the object code within the PBL, these files need to be pushed out when a repository is cloned. I can go into more detail on this if requested.
The PB IDE provides hooks for the MSSCCAPI interface so that it can support source code control providers. It works great with Visual Source Safe 6! But there are no usable MSSCCAPI providers for Mercurial. (I've asked before.) Yes, I'm trying to get the people that create PB to support an updated API, but there's no telling how long that will take. The IDE does, however, offer its own, basic, SCC functions. It's not a "real" solution; it's more of a "this will get you by, you cheap b*****d, until you can buy a real SCC program" type of thing. It works, though, by exporting the source for each class into individual text files and creating a corresponding "status" file (PRP file) for each class. Text files? Those can be tracked by Mercurial! FYI, this basic, "get you by" SCC option doesn't keep history or handle merges.
Let me detail a little more about these PRP files. PB's built-in SCC solution is built around exclusive locks. Check-out, check-in, all that old stuff. It manages these check-outs and check-ins via the PRP files. It also knows what is and what isn't under revision control by the presence of the corresponding PRP file.
So first with the PRP files. I need to have these pushed out (and added for new classes) so that the IDE can see that the corresponding class should be tracked. If there's no PRP file, the IDE doesn't export the syntax and nothing can get tracked in Mercurial. But if I continue to track changes to the PRP files, then that means that I'm pushing out the exclusive locks on the classes as well, and nobody wants that. So I need to add the PRP files but not track any subsequent changes to them.
And I need the same for the binary PBL files. As mentioned before, I need them to exist so that the IDE knows what PBLs make up a code base, but the complexities of the object code, compilation, and class inter-dependencies mean that it's not feasible to recreate them on the fly. So I need the PBLs added to Mercurial, but I don't really want to track the changes to those PBLs. And though I might be able to get by with templates for the PRP files, I can't do that for these binary PBL files.
Hopefully, that explains my situation fully. I apologize that this question is so long, but I wanted to make sure that you had a clear understanding of what I was up against so that I didn't get a bunch of off-the-cuff "This is a duplicate of X" responses. Thank you for your patience and for any guidance you can offer.
Even if I can't understand this
if I continue to track changes to the PRP files, then that means that I'm pushing out the exclusive locks on the classes as well, and nobody wants that. So I need to add the PRP files but not track any subsequent changes to them.
namely: "...nobody wants that..." and "...add the PRP files but not track any subsequent changes to them..." - if you don't version-contol changeable (and changed) sources I can't see reason to add outdated after fist change files to Mercurial
You can add, store and ignore later files in Mercurial. This answer play game nicely with small change: because you want .hgignore full working copy (really want?) you can use hg up -r N
Alternative solutions
SourceControl integration for PB 11.5 - TortoiseSVN (SVN)
WizSource - SCM on top of RDBMS
PushOk Git or SVN SCC plug-ins - Git or SVN respectively
I have a rather large project made up of lots of...projects, each with their own Debug and Release folders along with a bunch of other files that I don't really want to commit like .rc and .user.
At the moment I right click the top folder, click commit and eclipse asks how i would like to store all these "new files" it has detected, how do i tell it I don't want to commit any of them.
So far i have read that i need a .cvsignore file but that doesn't seem to make a difference. I tried doing a "clean" of the project but there was still plenty of files i don't want.
Does anyone have any advice on how to make this at the very least less painful? I have even tried doing a search on the project for certain . files I don't want and deleting them but some of them re-create themselves....
Note: I usually just commit the files I want by selecting them individually but this time it is about 600+ files...
UPDATE
Sorry for taking so long. Thank you to everyone for their answers, they are all technically correct, none actually worked for me, but i will mark Burhan as the best answer
I have tried the cvs ignore route before and it never seemed to work, unfortunately it still didn't work for me.
The per directory approach does seem to work but its quite a painful process in this case. But khmarbaise is correct this is the documented method, and is actually correct.
The Global method Burhan mentioned seemed ideal but didn't seem to work, Perhaps i have mis-understood where CVSROOT is, i always assumed it was the "CVS" folder located in the top most directory, it includes files like "Tag", "Root" etc. is this wrong?
#thkala, the "Team->Add to .cvsignore" was always greyed out for me and therefore could not be used but again is another valid route when it does work.
However I think i have finally realized why I have so many problems with CVS and eclipse and i would like to post what finally worked for me and what may actually be the missing link for the .cvsignore route.
I always checked the project out this way: CVS Repositoris -> Right click the branch -> check out as -> check out as project in the workspace.
However the reason i was having so many problems with cvs and indexing what i should have done is:
*CVS Repositoris -> Right click the branch -> check out as -> check out as ...New Project Wizard. -> retype branch -> Makefile Project with Existing code * (as a side note does anyone know how to specify the directory for the new project?)
Anyone who didn't do this and doesn't want to re-checkout can remove the project and re-add it using "new project"
At this point "Add to CVS ignore" was no longer greyed out. So you can now use that route if you want.
At this point however i tried something else i hadnt used before Team->synchronize with repo. This Seemed to bring up only the Changes i had made and therefore did not have any of the "new files" which was all the files i didn't want to commit. I was therefore able to simply double check the folders and then do a blanket commit on all those files in the sync view. It is really important to note that I actually had some build generated .h and .c files, so if i had succeeded in ignoring certain files, i would have still checked in these unwanted files (silver lining i suppose).
Perhaps i should rephrase the question to "large commit" to be more helpful to future cvs + eclipse newbies? anyone agree?
You can add a .cvsignore file on a per-directory basis containing the files in the directory that you want cvs to ignore. Note that if you want this to persist, you will have to commit that file too. #khmarbaise pointed to some documentation that talks about what kind of thing you can put in this file.
If you want to ignore certain file types on a global basis, then you should check out the CVSROOT module and make additions to the cvsignore file in that module (note that lack of a "dot" at the start of the name). Don't forget to commit this change for it to take effect.
Both .cvsignore and cvsignore files can contain the same types of information.
You can create a file which is call cvsignore which contains certan file types. I can't remember if it's called ".cvsignore" or "cvsignore". Check the documentation.
I've been all over google and SO looking for someone who has asked this question, but am coming up completely empty. I'll apologize in advance for the lengthy round-about way of asking the question. (If I was able to figure out how to encapsulate the problem, maybe I would have been successful in finding an answer.)
How are large projects managed in Mercurial, when the act of building / compiling generates hundreds of temporary files in order to create the end result?? Is .hgignore the only answer?
Example Scenario:
You have a project that wants to use some open source package for some feature, and needs to compile from source. So you go get the package. un-.tgz it and then slap it into its own Mercurial repository so you can then start tracking changes. Then you make all your changes, and run a build.
You test your end result, are happy with the results and are ready to commit back to your local clone of the repository. So you do an hg status to check your changes prior to committing The hg status results cause you to immediately start using all those words that would make your mother ashamed — because you now have screens and screens of "build cruft".
For the sake of argument say this package is MySQL or Apache: something that
you don't control and will be changing regularly,
leaves a whole lot of cruft behind in a whole lot of places, and
there is no guarantee the cruft won't change each time you get a new version from the external source.
Wow what? The particular project causing this angst is going to be worked on by multiple developers in multiple physical locations, and so needs to be as straightforward as possible. If there is too much involved they're not going to do it, and we'll have a bigger problem on our hands. (Sadly, some old dogs are not keen on learning new tricks...)
One proposed solution was that they would just have to commit everything locally before doing a make, so they have a "clean slate" they would then have to clone from to actually do the build in. That got shot down as (a) too many steps, and (b) not wanting to cruft up the history with a bunch of "time to build now" changesets.
Someone else has proposed that all the cruft just be committed into the Mercurial repository. I am strongly against that because then the next time around those files will turn up as "modified" and therefore be included in the changeset's file list.
We can't possibly be the only people who have run into this problem. So what is the "right" solution? Is our only recourse to try create a massively intelligent .hginore file? This makes me uneasy, because if I tell Mercurial to "ignore everything in this directory I haven't already told you about", then what happens if the next applied patch adds files into that ignored directory? (Mercurial will never see that new file, right?)
Hopefully this is not a completely stupid question with an obvious answer. I've compiled things from source many times before, but have never needed to apply version control on top of that. Plus we're new to Mercurial.
Two options:
The best option is to do an out of tree build, if you can. This is a build where you place the object files outside of the source tree. Some build systems, such as CMake, support this directly. For other systems, you need to be lucky since the upstream project must have added support for this in their Makefile or similar.
A more general option is to tell Mercurial to ignore specific types of files, not entire directories. This works well in my experience.
To test the second option, I wanted to compile Apache. However, it requires APR, so I tested with that instead. After checking in a clean apr-1.3.8.tar.bz2 I did ./configure; make and looked at the output of hg status. The first few pattens were easy:
syntax: glob
*~
*.o
*.lo
*.la
*.so
.libs/*
The remaining new files look like they are specific files generated by the build process. It's easy to add them too:
% hg status --unknown --no-status >> .hgignore
That also added .hgignore since I hadn't yet scheduled it for addition. Removing that I ended up with this .hgignore file:
syntax: glob
*~
*.o
*.lo
*.la
*.so
.libs/*
.make.dirs
Makefile
apr-1-config
apr-config.out
apr.exp
apr.pc
build/apr_rules.mk
build/apr_rules.out
build/pkg/pkginfo
config.log
config.nice
config.status
export_vars.c
exports.c
include/apr.h
include/arch/unix/apr_private.h
libtool
test/Makefile
test/internal/Makefile
I consider this a quite robust way to go about this in Mercurial or any other revision control system for that matter.
The best solution would be to fix the build process so that it behaves in a 'nice' manner.. namely allowing you to specify some separate directory to store intermediate files in (that could then be completely ignored via a very simple .hgignore entry... or not even within the version-controlled directory structure at all.
For what it's worth, I've found that in this situation a smart .hgignore is the only solution that has worked for me so far. With the inclusion of regular expression support, it's very powerful, but tricky, too, since a pattern that is cruft in one directory may well be source in another.
At least you can check in the .hgignore and share it with your developers. That way the work is only done once.
[Edit] At least, however, it's possible -- as noted above by Martin Geisler -- to have full path specifications in your .hgignore file; you can, therefore, have test/Makefile in the .hgignore and still have Mercurial notice a new test2/Makefile
His process for creating the file should give you almost what you want, and you can tune it from there.
One option you have is to clean your working directory after verifying a build.
make clean
hg status
Of course you may not want to clean your project if it takes more than a few minutes to build.
If the files you want to track are already known to hg, you can hgignore everything. Then you need to use hg import to add patch, and not just use the patch command (since hg needs to be aware if some new files should be tracked).
How about a shell (or whatever) script that walks your build directory recursively, finds every file created after your build process started running, and moves all these files (of course, you can specify the exceptions) into a cruft_dir subdirectory. Then you can just put cruft_dir/* in .hgignore.
EDIT: I forgot to add, but this is fairly obvious, that this shell script runs automatically as soon as your build finishes. Maybe it's even called as the last command in your Makefile/ant/whatever file.
What I currently do is I link the project to another location and give it the same name, then check the box where it says "Branch after share."
And then I would Check out the shared project and work off it. And finally merge with the original project.
This works okay, but it feels very clunky: I have multiple instances of the project on my drive; I have to change physical address of the website (i use asp.net 1.1) every time I work on a different branch;
That doesn't feel like the right way to do it. How do you branch your projects with VSS?
I think the way you describe in the question is the only way you can do it in sourceSafe.
I usually name the copied directory "V1.0" (or whatever is appropriate) and keep them all in a folder that is the main project name.
That is the generally accepted way of branching your source code in SourceSafe. The only other way to do it, if merging and retaining the history are not an issue, is to copy the files to a new folder, remove the read-only attribute, remove the .vssscc and .scc files, and then add that new project to SourceSafe. At that point, you have an all new project, with no prior history.
You can find a good reference here: http://www.codepool.biz/version-control/sourcesafe/branch-in-sourcesafe-vss.html
Basically right-click-drag your folder to where you want a branch, and when you let go you are given share/branch/recursive options.
Shudder.
The way you described is the only supported way to do "branching". And as you pointed out it is rather clunky. In VSS it's best to avoid branching alltogether as it will destroy your source history.