[cvsnt] cvsnt Digest, Vol 65, Issue 34

Sanjeev, Neeraja (GE Infra, Energy) neeraja.sanjeev at ge.com
Tue May 27 12:41:24 BST 2008


Hi Bo,

I understand the revisioning. But sometimes you have made changes and
checked in. Now you want to revert the changes  you have made and work
with older version. 

In that case how we need to proceed further?

Thanks,
Neeraja

-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of cvsnt-request at cvsnt.org
Sent: Tuesday, May 27, 2008 4:30 PM
To: cvsnt at cvsnt.org
Subject: cvsnt Digest, Vol 65, Issue 34

Send cvsnt mailing list submissions to
	cvsnt at cvsnt.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
or, via email, send a message with subject or body 'help' to
	cvsnt-request at cvsnt.org

You can reach the person managing the list at
	cvsnt-owner at cvsnt.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cvsnt digest..."


Today's Topics:

   1. Re: Merging problems, getting strange conflicts.... (Bo Berglund)
   2. Re: Checking in Older versions (Bo Berglund)


----------------------------------------------------------------------

Message: 1
Date: Tue, 27 May 2008 12:39:48 +0200
From: "Bo Berglund" <Bo.Berglund at system3r.se>
Subject: Re: [cvsnt] Merging problems, getting strange conflicts....
To: <cvsnt at cvsnt.org>
Message-ID:
	
<C66EBC6C8B31CC488641B94D31FD86589A8D1C at 3REXCHANGE02.system3r.com>
Content-Type: text/plain;	charset="us-ascii"

Concerning 2-way merges I am not talking about such. Mu merges are 1-way
only, first from Trunk to Branch and then later another 1-way from
Branch to Trunk.
The sequence is:

- Branch off trunk at say rev 1.8
- Make changes on branch to arrive at 1.8.2.9
- Also change trunk to get 1.11
- Now merge HEAD into branch and resolve conflicts (1-way)
- Commit to get 1.8.2.10
- Now there is a mergepoint set on 1.8.2.10 pointing back to 1.11
- Next try the merge from branch to head (also 1-way) and get the
conflicts

I always thought that the mergepoints recorded pairs of revisions that
were already merged such that the receiving end had all the changes from
the branchpoint included.
In my case above after the first merge the branch would contain all of
the head changes in addition to the branch changes and this is noted by
the mergepoint.

Now, in the second (1-way) merge CVSNT should have noted that 1.8.2.10
(tip of branch) already contained all of the head changes from the
original branch point to the HEAD revision 1.11 since the mergepoints
would tell it so.
Consequently there is no need to get any data from HEAD, just copy over
the contents of branch in the merge process.

But what happens is that it announces conflicts where there are same
location changes even though the valid such conflicts were already
solved in the first merge/commit.

So why are the mergepoints not used?

(Sorry about the top-posting, I am doing this from work where
newsreaders do not work and Outlook is not able to format my reply
properly...)

Best regards,

Bo Berglund


-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of Arthur Barrett
Sent: den 27 maj 2008 02:02
To: cvsnt at cvsnt.org
Subject: Re: [cvsnt] Merging problems, getting strange conflicts....

Bo,


> Now my TCPIP branch is working fine and I need to move it to TRUNK. In
> preparation for this I merged HEAD into the branch and solved the
> conflicts (because HEAD had changed a lot less than Branch over the
> months). I thought that by doing this the final merge from branch to
> trunk would be almost automatic.

There was a really long thread on this ages ago.  I think Gerhard was
involved in a lot of it and may even have written something up
afterwards in the wiki.  The short summary is that CVSNT cannot do
bidirectional merging.  I think after that discussion Tony may have made
some changes to the merge code to support a single suggestion that was
made - if I'm remembering correctly then that'll be in 2.5.04 only and I
think your production system is 2.5.03 - but I'm not sure it'd cover
this case.

The recommended approach is to merge branch to trunk with no merge from
trunk to branch (you did this as a 'prep' step which is simply
unnecessary since the trunk is not locked or changed until you actually
commit the merge.  Alternativly there is the 'copy branch to trunk' or
'make trunk equivalent to branch' method.

Regards,


Arthur

_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt


------------------------------

Message: 2
Date: Tue, 27 May 2008 12:46:55 +0200
From: "Bo Berglund" <Bo.Berglund at system3r.se>
Subject: Re: [cvsnt] Checking in Older versions
To: "Sanjeev, Neeraja (GE Infra, Energy)" <neeraja.sanjeev at ge.com>,
	<cvsnt at cvsnt.org>
Message-ID:
	
<C66EBC6C8B31CC488641B94D31FD86589A8D1F at 3REXCHANGE02.system3r.com>
Content-Type: text/plain;	charset="us-ascii"

I think you do not fully understand the way CVS works.
A file under version control is managed on the server by adding new
revisions for each committed change you make to the file.
Such a new revision can only be based on the *latest* revision of that
file either on the main line (TRUNK) or on a branch.

If you have checked out a file and updated it to a past revision (one
that is not the latest one on the server), say that you have revision
1.13, and then you want to edit it and commit the result, you will fail.
The reason is that the successor of 1.13 is 1.14, so a commit of your
edited file should create 1.14.
But it can't because 1.14 already exists!

The way to handle this is to create a branch off the code at some time
in the past and then put the sandbox on that branch.
In that case you would be able to commit the changes to 1.13 to arrive
at 1.13.2.1, signifying that the file is located on a branch.

Don't ever mess with the CVS subdirectory of your sandbox and its
contents! As soon as you remove it the files stop being under version
control on your PC (they are still on the server of course) and cannot
be committed at all anymore!


Best regards,

Bo Berglund


-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of Sanjeev, Neeraja (GE Infra, Energy)
Sent: den 27 maj 2008 10:36
To: cvsnt at cvsnt.org
Subject: [cvsnt] Checking in Older versions

Hi,

I was trying to checkin the olderversion of the file. It failed.  
I think it might succeed if I do not get the cvs directory of the old
version.
Is there any way or CVS command available to checkin the older version
of the file?
Is there option available to update the directory by ignoring the CVS
directory?

Thanks,
Neeraja
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt


------------------------------

_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

End of cvsnt Digest, Vol 65, Issue 34
*************************************


More information about the cvsnt mailing list