I've tried searching for answers to my problem but every thread starts talking about branches and trunks and I have no idea what they're talking about.
I'm in a team of 2. We've started working on a single excel spreadsheet. I use SVN update before making my changes, however while I'm making changes, my team-mate also makes changes and commits them before I do.
I was first told that I simply have to update again before I commit and it should merge my team-mate's changes with mine. However when I update the .xlsx file, nothing seems to happen. I open up my local copy again and it isn't showing my team-mates changes. I've tried using the merge option and clicked random things in numerous attempts but nothing works. Nothing I've tried will add my team-mates changes to my working copy. Every time I compare my working copy with the repository, the changes from both of us are all highlighted, but nothing I do seems to merge them together.
The cells we modify in the spreadsheet are different ones, so we don't both make direct changes to the same cell. It should be a simple merge.
This is driving me up the wall, it keeps saying "merge successful" or "update successful" but it isn't doing anything.
.xlsx files are not text-files (they are really zip-archives), don't expect merging of such files from Subversion in any case
You can't have easy teamwork with Office's documents
First of all, xlsx files are binary rather than textual so SVN cannot merge them very well. So two of you working on one such file at the same time will not work well even if nothing goes wrong.
As for why you never saw the changes, probably you still had the file with your changes open in Excel when you did your update, and Excel never prompted to load the new changes.
To correct the immediate situation you can move your version of the file elsewhere, svn update to get the repository version back, and manually compare and resolve the differences.
In the future, since SVN is not suited well for merging this type of file, set the svn:needs-lock property on this file, and always be sure to svn lock it before editing to keep your coworkers from making changes at the same time.
If you need simultaneous editing capabilities, look into what cloud services Microsoft offers, or switch to Google Docs or similar.
Related
Here's the scenario -
Development branch was created from mainline, with many thousands
of files in it
A couple of thousand files were modified.
Changes from mainline were "p4 integrated" into the branch.
Hopefully integrations always included the complete mainline as of a
known-good label, but I'm not sure of this
Steps 2 and 3 were repeated an unknown number of times - let's guess
a dozen integrates, and probably another 1000 or more changes,
usually to files already modified
I am now in the painful position of trying to code review this.
Are there any commands that can help me get the diffs for each modified file between the version last integrated to it, and the version in the branch?
Or do I need to write:
A script which will identify all locally changed files.
A script which will find the integration point for each file in the above list
Another script which will use (2) to purge the list in (1) of files with no net change
A wrapper on (2) that will issue an appropriate p4 diff2 command
FWIW, I basically know how to do this manually, file by file. It's the scale that's daunting. Also, there are changes still going into the branch, in response to code review feedback, so I'll probably be recreating my lists repeatedly.
If you know what the known-good label in the mainline was that was used to do the last integrate, this should just be:
p4 diff2 main/...#good-label dev-branch/...
since for each file "the version last integrated" will be #good-label. Files that weren't locally modified won't have any diffs, so there's no special need to filter them out.
FWIW if I were in your position I'd be making use of "p4 ichanges dev-branch/... main/..." and going through by changelist, since diffs make more sense when each is in the context of its changelist, rather than looking at one monster diff per file that each contains a dozen unrelated changes.
I wanted to transfer my work from on pc to another (at home). I checked in a shelve set on my main pc. I pulled it from my laptop fine. I then updated my code on my main pc and made another shelve set. I pulled it again on my laptop. It was taking some, so I cancelled the operation and deleted the whole directory on my laptop disk. When I tried getting the shelve set again I just get
Multiple error occurred during the operations, the first of which is
displayed below. A full error list is available in the Output Window
You cannot unshelve a change to $/Business/Path/Logic because there is
a conflict on this item in your workspace
The output window lists about 100 of these:
You cannot unshelve a change to $/Business/Path/Logic/app.config because there is
a conflict on this item in your workspace. You must first resolve the conflict or exclude this file when you unshelve the shelveset.
What? I just want a new copy of the latest shelve set. I tried mapping to a new path on my laptop, but same thing.
Thanks
Thomas
Sounds like when you "deleted the whole directory" on your laptop source control actually picked this up as a change. If that is the case your laptop should actually show that you have changes in your "My work" area. If you do and didn't really intend to make that change just undo the checkout.
This version of VS is a little different... even if you make a change using the Explorer and not within the VS source control explorer it can pick that change up. This is normally a great thing... you can use whatever editor you like and it will count that as a change. But you have to be aware that it is going to do that so that you don't accidently make unintended changes.
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
Two people were working on the same file at the same time unknowingly. One person committed changes to the Repo, making the second persons file out of date.
Is there a way to merge and keep both set of changes without, making the second person, move his/her file, re-update the folder to get the other persons changes, and then copy the changes he/she made into the updated file and then commit to the repo?
Thanks in advance.
Have the second user do an "Update" on his code. If they were not working with the same lines of code within the file, the Update will merge the first user's changes into the second user's code. Then the second user can just commit his code normally.
If they were working on the same lines of code, a conflict will occur and must be resolved manually, by the second user. Tortoise provides a GUI for making this manual conflict resolution a bit easier.
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html