Problems with merge
Hi! I think this is a little dummy question but I read the CVS manuals and didn't find nothing that could help me on this. - This is the scenarion: I made a branch on a cvs file (on the 1.4 revision of index.html, for example). Then I work on this branch naturaly. Besides that, I don't create no other revision on the main trunk. After all the necessary modifications, I tried to merge the lastest file revision of the branch with the lastest file revision of the main trunk (the 1.4 revision of index.html) to create the 1.5 revision of this file. - This is the problem: The problem is that this merge, in some cases, creates a conflict. I thought that it would not happen because the lastest revision file of the branch is from the 1.4 revision that I want to merge with. So, why the conflict is happening. There is anyway to ignore the conflict and accept the changes added on the lastest revision of the branch? Thanks! -- João Ronaldo Del Ducca Cunha, Bsc. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is import really necessary?
Hello,
* On Tue, Dec 21, 2004 at 02:54:23AM + Mike wrote:
cvs co -ldtop .
cd top
mv /home/user/newtree .
find newtree -exec cvs add {} \;
cvs ci
Hmmm. I like this! Is it possible to use an import-less approach
like this one if top is one's home directory (meaning that there will
be a lot of other stuff there besides newtree)?
Yes, almost...
You can do a
cvs co -ldtop .
cd top
mkdir newtree/
cvs add newtree
cd newtree
mv /home/user/* .
find newtree -exec cvs add {} \;
cvs ci
BTW: Personally, I would prefer to not move (mv) everything, but to
copy (cp -pr) it.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://www.viceteam.org/
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: issue 108
Aldo TENDRON writes:
If there is no markers in the merged file (', ===, '), is it save
to remove by hand the Result of Merge text from Entries file ? Or is
there a case that cvs st should return File had conflicts on merge
even if there is no markers in the merged file ?
You're confused -- Result of merge doesn't indicate that the file has
conflicts, it just means that the file was modified by a merge. It
should stay in the Entries file until you commit the changes.
-Larry Jones
You don't get to be Mom if you can't fix everything just right. -- Calvin
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: issue 108
You're confused -- Result of merge doesn't indicate that the file has conflicts, it just means that the file was modified by a merge. It should stay in the Entries file until you commit the changes. According to issue #107 and #108, cvs st returns File had conflicts on merge in this case (on Windows): - 'cvs up myfile' inserts conflicts markers in myfile - 'cvs st myfile' returns File had conflicts on merge - I resolve conflicts - 'cvs st myfile' still returns File had conflicts on merge if I delete Result of merge in Entries file, 'cvs st myfile' returns Locally modified. It is confusing that 'cvs st' says File had conflicts on merge whereas there is no conflict anymore. Removing Result of merge makes 'cvs st' behave 'correctly', but I'm not sure this is side-effect free. Can I use this trick ? -- Aldo Tendron ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Local access to network share not supported (Use -N to override t his error).
Hi All I am having problems accessing my repository since its a local repository stored on a network drive. I am being told to add the -N option to all cvs commands to make it work, and yes indeed that works when I type the commands myself. What I am not able to do is to make this default behavior. i.e. I don't want to add it manually to every command everytime One possible solution to my problem woud probably be to modify the .cvsrc file. I looked as suggested into the .cvsrc file, made sure that my $homepath, $HOME and $HOMEDRIVE environment variables point to the right place and put the .cvsrc file there: Its as if the cvsrc file is not being used. BTW, the content of the .cvsrc file is the following: cvs -N commit -N cvs commit -N My question 1) Where am I to enter the -N option so that it is automatically invoked everytime? 2) How am I to configure my environment variables so that the .cvsrc file is seen? Best regards Adourian ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Changing CVS Notify from Mail to use ICQ?
Title: Message Hi all: Has anyone been able tochange the cvs notify from using email to another method of message delivery? I'm looking for delivering those notifications via icq. Any hacks out there? Attempted to email to icqnumber@pager.icq.com but got nothing. Any other suggestions or directions? Thanks for your time, Rich ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Changing CVS Notify from Mail to use ICQ?
Hello, * On Wed, Dec 22, 2004 at 12:22:56PM -0500 Rich Snowdon-Smith wrote: Has anyone been able to change the cvs notify from using email to another method of message delivery? I'm looking for delivering those notifications via icq. Any hacks out there? Attempted to email to icqnumber@pager.icq.com but got nothing. Any other suggestions or directions? There are tools for ICQ which can be used from the command-line. One of these tools is centericq. If you have a running instance of it, you can use the --send option to send a message. Another option would be to try to set a RSS/RDF feed. Again, centericq can treat these like a contact from some other person. Just some ideas, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
problem adding files to a branch
Hi, We're having a problem adding files to a branch in our repository. We're using cvs version 1.11.17, with both clients and server on linux. This is the detail: $ cvs add test.txt cvs add: cannot add file on non-branch tag uwap_3_1-RELEASE This is the status of one file in the directory (so you get some information - i've changed our repository location to an alias): $cvs status formats.txt === File: formats.txt Status: Up-to-date Working revision:1.1 Repository revision: 1.1 repository/formats.txt,v Sticky Tag: uwap_3_1-RELEASE (branch: 1.1.6) Sticky Date: (none) Sticky Options: (none) $cvs status -v formats.txt === File: formats.txt Status: Up-to-date Working revision:1.1 Repository revision: 1.1 repository/formats.txt,v Sticky Tag: uwap_3_1-RELEASE (branch: 1.1.6) Sticky Date: (none) Sticky Options: (none) Existing Tags: test_branch (branch: 1.1.8) uwap_3_1_1-RELEASE (revision: 1.1) wap_3_1-RELEASE (revision: 1.1) uwap_3_1-RELEASE(branch: 1.1.6) wap_3_0-RELEASE (branch: 1.1.4) wap_3_0_1-RELEASE (revision: 1.1) uwap_3_0-RELEASE(branch: 1.1.2) -- I checked all files, and I don't see any where the branch name is a tag (i.e. it doesn't seem to be the problem, as i've found when googling that error). Any idea what's going on? Regards, Jean-Pierre Sevigny ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Root of hierachy
Thanks Larry, that was a big step forward for me, the beginner. I'm hoping to understand the philosophy of CVS now. Xmas greetings and a happy new year from ngc891. Larry Jones wrote: ngc891 writes: As you said, this it not how CVS works. Please tell me, how does CVS works. I didn't found it anywhere in the internet (I was looking for it for 3 month :-) ) Have you tried reading the manual? https://www.cvshome.org/docs/manual/ -Larry Jones Why can't I ever build character in a Miami condo or a casino somewhere? -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: problem adding files to a branch
Jean-Pierre Sevigny [EMAIL PROTECTED] wrote: $ cvs add test.txt cvs add: cannot add file on non-branch tag uwap_3_1-RELEASE Do you have a CVS/Tag file ? If so, what does it contain ? -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
ISO version control file merge tool (merge RCS/CVS ,v files)
---++ VC Merge So here is what I want: given two version control files, supposedly for the same file, merge them. The merge may range from trivial to fancy. All merges should preserve all history and comments; however, some merges may do better than others at recognizing commonality between ostensibly different versions. Similarly, some merges may be more space efficient than others ---++ Commonalities and Differences between VC Tools I'll talk about this as if it is a tool that merges CVS/RCS ,v files. I believe it should generalize fairly well to other VC tools, but what I need now is CVS. CVS is my legacy VC system. Pretty much all tools understand * files * versions of files * branches * check in comments Some tools handle groups of files together, but I don't think this matters to the discussion here. Some tools don't really have a concept of a branch - notably Subversion, where a branch is just a different directory in the Subversion filesystem. However, in Subversion you can trace ancestry, and figure out branching, although it can be hard to distinguish branching in the Subversion VC system from moving a file to a different location in irectory hierarchy. Some tools understand more complicated graphs than simple branching: they can track cross-links, branches that merge back, etc. I think this can be handled. Some tools get confused if a filename has different types in different versions - e.g. CVS, change from a binary to a text file. Other tools handle this - e.g. MetaCVS, giving a file a unique name at initial checkin. If you delete and then re-add a file, it gets a new unique name. Some tools totally separate names from content - e.g. Monotone. For all tools, it should be possible to write code that traverses the tree, handling branches depth-first, bread-first, or whatever. ---+++ Trivial Merge - No Sharing The most trivial merge replicates all branches, and doesn't try to share anything. Input: verbatim repo1 A-v1.1-v1.2-v1.3 +-v1.1.1.1-v1.1.1.2 /verbatim verbatim repo2 A-v1.1-v1.2-v1.3-v1.4 +-v1.1.1.1 /verbatim Output: union of all branches and versions verbatim A-+-repo1branch-v1.1-v1.2-v1.3 | +-v1.1.1.1-v1.1.1.2 +-repo2branch-v1.1-v1.2-v1.3-v1.4 +-v1.1.1.1 /verbatim This exposes some minor issues: * in a CVS-like system, who gets the main branch * A: option. Default nobody * what about tags and labels * Default: all made unique by, e.g. adding a prefix. * Advanced: may want to recognize sharability ---+++ Types of Sharing Same data, same version: In the above example, repo1/A v1.1, v1.2, may be the same as repo2/A v1.1 and v1.2. Same data, different versions: repo1/A v1.3 may be the same as repo2/A v1.4. i.e. the main branch of repo1 may have skipped a version that was on repo2's main branch. (It's just accidental that I say main branch for this example.) ---+++ Trivial Merge - Recognize Sharing A trivial merge might recognize sharing, but not change the trivial concatenation of all branches. E.g. it would still have the union of all branches and versions, but might add comments indicating commonality. * fileA * repo1branch * main branch (v1.*) * v1.1 * v1.1.1.* branch * v1.1.1.1 * v1.1.1.2 * v1.2 * v1.3 * repo2branch * main branch (v1.*) * v1.1 * same as fileA/repo1branch/v1.2 * v1.1.1.* branch * v1.1.1.1 * same as fileA/repo1branch/v1.1.1.1 * v1.2 * same as fileA/repo1branch/v1.2 * v1.3 * v1.4 * same as fileA/repo1branch/v1.3 In this example, I only indicated when files from repo2 were the'same as files from repo1; i.e. I only indicated one direction. It could be made bidirectional. These same as comments might just be that - comments. However, they could also be links understood by the version control tool, to reduce the amount of data stored. Different version control tools store different amounts of data. Subversion, for example, at one time stored a full version at the head of a branch. This wasted space. Monotone, however, will only store any given set of bytes once - Monotone is content based. Thus, recognizing sharing may save space. However, more important is what recognizing sharing does to the user perception of history. ---+++ Common Ancestor Tree Merge A basic form of tree-oriented merge would not replicate branches from repositories until there is a difference. At the point of divergence, it would provide the union of all diverging branches. * fileA * main branch (v1.*) * v1.1 * common to both repo1 and repo2 * v1.1.1.* branch * v1.1.1.1 * common to both repo1 and
Re: Local access to network share not supported (Use -N to override t
Adourian, Chahe writes: I am having problems accessing my repository since its a local repository stored on a network drive. That is an extremely foolish thing to do. Essentially every report of repository corruption we've ever received has been caused by a network mounted repository. You should either put the repository on a local drive or use client/server mode with the disk local to the server. I am being told to add the -N option to all cvs commands to make it work, and yes indeed that works when I type the commands myself. Then you must be using CVSNT rather than standard CVS, so you're asking in the wrong place. (See http://www.cvsnt.org/ for information on CVSNT support.) -Larry Jones All girls should be shipped to Pluto--that's what I say. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: problem adding files to a branch
Hi Sevi, We too had a similar problem and I dont remember how we got this. But as far as my memory goes, when we tag a branch code, it gets created as a branch or something. I dont remember that. That was a serious probelm though. We had to avoid that. Regards Sandhya Hi, We're having a problem adding files to a branch in our repository. We're using cvs version 1.11.17, with both clients and server on linux. This is the detail: $ cvs add test.txt cvs add: cannot add file on non-branch tag uwap_3_1-RELEASE This is the status of one file in the directory (so you get some information - i've changed our repository location to an alias): $cvs status formats.txt === File: formats.txt Status: Up-to-date Working revision:1.1 Repository revision: 1.1 repository/formats.txt,v Sticky Tag: uwap_3_1-RELEASE (branch: 1.1.6) Sticky Date: (none) Sticky Options: (none) $cvs status -v formats.txt === File: formats.txt Status: Up-to-date Working revision:1.1 Repository revision: 1.1 repository/formats.txt,v Sticky Tag: uwap_3_1-RELEASE (branch: 1.1.6) Sticky Date: (none) Sticky Options: (none) Existing Tags: test_branch (branch: 1.1.8) uwap_3_1_1-RELEASE (revision: 1.1) wap_3_1-RELEASE (revision: 1.1) uwap_3_1-RELEASE(branch: 1.1.6) wap_3_0-RELEASE (branch: 1.1.4) wap_3_0_1-RELEASE (revision: 1.1) uwap_3_0-RELEASE(branch: 1.1.2) -- I checked all files, and I don't see any where the branch name is a tag (i.e. it doesn't seem to be the problem, as i've found when googling that error). Any idea what's going on? Regards, Jean-Pierre Sevigny ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
