I'm using P4V. I work in a subdirectory (eg code/jorge) and other people work in another subdirectory (eg art/) that I never deal with. Additionally I have a stream where I do my personal work. Every so often I need to merge changes from the main line to my stream, and copy them back up. However, the files in art/ are large binaries and Perforce spends a long time thinking about them even though I've not touched them. Is there any way to have perforce merge/copy my directory (code/jorge) without it spending time trying to merge art/? Can I tell P4V to merge/copy only the code directory?
Related but not identical question: Perforce streams, exclude files from merge/copy
If you don't touch those files, it might be easier to not include them in your stream at all rather than manually exclude them every time you do a merge.
I.e. if your stream Paths currently says:
share ...
maybe it should instead be:
share code/jorge/...
or, if you need the art for builds but never need to modify it, you might consider doing something like:
import art/...
share code/...
I am not sure this is the recommended option but you can actually merge without using the "Stream to Stream" option but the standard "Specify source and target file" options, even if you are in a stream depot.
So you can select any subdirectory as your source like 'dev/code/jorge' and the same subdirectory as destination like "main/code/jorge' and it will only consider that directory. We do it routinely in my team because we have a big mono repo and have not taken the time to setup multiple depots when we migrated to Perforce.
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 am about to start participating in the development of a medium-sized project (~50k lines) that was until now written by a single person, and not versioned; as a result folders are cluttered with different versions of the same file (named file1, file2, file3, etc.).
I proposed to start using a VCS for it (a priori Mercurial, which is the only one I've ever used -- for my personal projects --, but I'm open to suggestions), so I'm taking any good ideas as to how to "start" the repository. E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed? Or something else?
(constructive remarks on mercurial vs bazaar vs git vs whatever are also welcome.)
Thanks for your tips.
E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed?
If the size of the repository is not a concern, then yes, that is a good starting point. Otherwise you can just commit what's actually used, and go from there.
As for which system, all DVCSes stick to the same core principles. Which one you pick is entirely subjective — the only way to truly know which one you like is to try each one.
I would say use what you are the most comfortable with and meets your needs. As far as where to start, I personally would seed the repo with the current source as is, that way you can verify that everything builds and runs as expected. you can make this initial seed a branch. That way you can always go back to your starting point before refactoring.
My approach to this was:
create a Mercurial repository in the existing project folder ("existing")
commit all project files to "existing"
create an empty repository in what a different location ("new")
As files are tested and QA'd (this was necessary because there was so much dross in "existing") pull them from "everything" to "new".
Once files had been pulled into "new"; delete the corresponding files from "existing". If access is needed to these files while the migration is under way, push them back from "new" to "existing".
This gave me the advantage of putting everything under some sort of control for recovery purposes, control over introducing the project to the DVCS. Eventually the existing project folder became completely tested and approved for the project moving forward. At this point the "everything" directory could be deleted or changed into a working folder; and "new" became the actual project folder.
I think Mercurial is a good choice. Lightweight, fast, very simple to use and well-integrated with Windows (if that's the platform you're dealing with).
I would probably get rid of all the clutter before the first commit. Delete everything you don't care about, run all the necessary tests and only then do the commit.
Yes, I'm dead set against the 0-day cluttering of repos.
Granted, a 50K SLOC project isn't very big, but if you commit files you already know you won't need, they will make your repo slightly bigger.
Also, remember to check that the tree doesn't contain large binary files. If it does, get rid of them if at all possible.
Does Perforce supports file streams on Windows, on NTFS?
Sorry to resurrect such an old thread, but I found a workaround that will allow Perforce clients (P4/P4V) to create ADS data.
Chapter 2 of the Perforce Users Guide has a section titled "Mapping files to different locations in the workspace". This section covers how to remap the depot to the workspace and vice-versa.
Let's assume that you want to store some asset metadata with your files in Perforce. You create a tool that generates an ADS called asset.meta such that your filenames are of the form file.ext:asset.meta.
If you modify your Perforce Workspace to include the following:
//depot/....asset.meta //CLIENT/...:asset.meta
This will take ADS asset.meta streams and create files for them in Perforce.
foo.txt with an asset.meta ADS gets stored as 2 files in the depot: foo.txt and foo.txt.asset.meta. When you sync them down, they end joined correctly.
Now there are 2 caviats to be aware of.
1.) P4V will not see the ADSs. You have to add them manually through P4, the P4API or some other explicit mechanism.
2.) If the base file (foo.txt from our example) is not marked writable, you will not be able to sync the ADS.
You will have to deal with #1 in whatever way you want. #2 is trickier IMO. You can +w the main files so they are always writable on the client (if your workflows can accommodate that), or you can write a custom sync routine that handles making files read-only or read-write as necessary.
I may respond to this if I hear any good ideas from Perforce other than the ones mentioned above, but considering how high this page shows up in Google when searching for "Perforce Alternate Data Stream", I thought this might help someone.
I just got a response from Perforce:
Perforce does not have any special support for NTFS Alternate Data Streams.
This means that you will lose any additional data stream when you submit a file into perforce.
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.
Our product is game-like, and is very rich (~40M - 100M) in binary supporting files - textures, meshes, movies etc. Like kai1968, I'd like to be able to sync-in these assets, and not just code, with a single click.
Strictly speaking, however, that is different than version control: I have no desire to burden our TFS with irrelevant history of these files. Can I somehow upload stuff without keeping history to TFS? It would be even better if I could opt to keep history at specific points (say, label points), and not in every checkin.
More generally, how do you manage sync of binary assets?
(I'm aware of other tools, perhaps better suited for such tasks, but diverging - or altogether migrating - from TFS is not an option right now.)
We've always kept binary assets in TFS when we need to, and just dealt with the side-effects of that choice (extra storage, longer check-ins because you can't diff on binaries, etc). I don't believe there's a way to selectively destroy the history of certain files, except manually. If you want to do this periodically, by hand, you could do the following:
Get a curent copy of the binary files
Destroy (delete with history) the binary copies in TFS
Manually add the files back to TFS
You'd have only the most recent copy, but this has a side-effect - you'd break any previous builds, since an attempt to retrieve source history wouldn't return these new copies of the files. TFS would check for a copy that matches the checkout you're attempting, and finding none, it wouldn't retrieve a copy of those files. You'd need to update your build scripts to pull the most recent binaries, as well as the historical code, if you wanted to build an old version, but even then, it won't be a true history.
The second option is to only check them in periodically - not with every single minor change. For example, keep these files somewhere safe (a file share with daily backups), and then only check in the changed binaries every week or so, or before every label, or whatever - this way, you don't have incremental history, but you'd still have your label history. You might even consider writing some kind of automated routine to apply labels, where it would check in any changes in that folder first, then apply the label.
Please post back what you end up doing - I'm curious to know!
Here are a few thoughts:
Consider using a separate VSTS project, so you don't mix the binaries and code in the same project. This makes it a bit easier to manage (e.g. you can keep the assets separate, and also any work items relating to them are more easily queried by filtering on the project). On the down side, this would mean 2 clicks to get latest.
Why don't you want to keep histories? The point of source control is to keep history so you can go back to a particular build for a particular day. Otherwise, you might as well just use a backup program on a network drive (and you really don't want to do that!)
If you're only worried about disk space usage, then don't. 100MB is tiny, and hard drives are cheap. My last game project had hundreds of gigabytes of assets and we kept the history of every change for over 3 years.
The assets won't slow anything down. They only take time to process if you check them in or Get them, which are both activities you will need to do even if you don't use source control. Indeed, source control makes things faster because you have a "one click does it all" solution.
The many other benefits of source control are really useful on assets, and vastly outweigh the negatives.