This file is maintained by project infrastructure.

genfiles.properties should be versioned in parallel with other nbproject files.
If CVS reports a conflict there is a real conflict of some kind - another user
checked in a revision to this file whereas your IDE also needed to rev it. Might
be duplicate of issue #42735, though there are no steps to reproduce so it is
hard to say.

Reopen, coz the problem still exits. 

Per a conversation on the Netbeans (NB) users list, I am going to add some additional comments about my experience and 
maybe add a suggestion or two.

This whole issue and the related issues seem to have something to do with the thinking that the either the "metadata" 
properties of NB (nbproject folder, etc) do not belong in versioning control or that there is nothing that can be done 
when conflicts occur between some files in these folders.  Personally, I am having a hard time understanding 
particular viewpoint of what the NB community expects should happen or how users might work around these issues.  So 
if someone wants to comment, please do so.

First, the specific issue that we have ran into is the fact that sometimes during development of a project through NB, 
NB will update the files in the "nbproject" folder.  Either due to project property changes or whatever.  We had a 
situation (and we have had it numerous time) where NB would modify the genfiles.properties file.  Thus when a merge 
through the NB's CVS engine there is a conflict with the genfile.properties.  Well, NB does not allow you to resolve 
the conflict like a normal project file.  In fact, the project becomes corrupt in NB and all you see is "???" where 
the project name is supposed to be.  I have even used the "revert" command on that particular file and the project 
still remains corrupted.  To resolve the issue we have to delete the project and check the branch out again.  

The above is the specific reason I started down the trail of trying to determine if this was a previous bug or just 
some random issue.  I was led to this issue number and also all the related issues.  I read each post and plus some 
other discussions on the users list and thus I am posting here, becuase I still feel this is an issue and I am 
wondering how such a problem can still be a problem.  Be bear with the next paragraph or so because it might be filled 
with some rhetorical questions and slight ranting, but I want to express my viewpoint and I am curious to see other 
people's viewpoints on this matter.

Our shop uses Netbeans exclusively.  We made a business decision to use NB because of its support for maintaining and 
creating build scripts.  Why reinvent the wheel, right?  The solution that has been suggested was for us to just put 
the "source" code under CVS and not the project information, which means uses a free form project.  Thus, losing what 
NB is giving us in the first place.

As everyone knows, there are certain files created and maintained by the IDE and the project settings that users 
select from the GUI wizards.  The users do not usually modify these files.  Since these files are updated by NB, would 
it not be feasible to have all control of these files be handled by NB?  If someone wants to merge from a CVS branch 
and the project specific files have been changed, then could the IDE either merge the project property files, ignore 
the project property files during the merge, or just rebuild the project properties files based upon the current 
settings of the user's project.  NB could determine which way to go based upon a project setting or even an IDE 
setting.

My intention is not to put anyone's thought process down, but to have a better understanding of where to take this 
issue and whether or not the community feels this is really an issue?

Steps to reproduce?  Might be hard to do, but here is what I suggest:
Create a project in NB and import the project into CVS.  Create a branch of the project.  Checkout the trunk and make 
some specific changes that will cause the genfiles.properties to be updated (I do not know specifically what will 
cause this file to change, but I am sure someone does).  Commit.  Delete the project completely from NBs and from your 
working directory.  Checkout the branch previously created.  Make some more changes that will cause the 
genfiles.properties to be updated.  Commit.  Then do a CVS merge from trunk into this working copy and there should be 
a conflict with genfile.properties file.  If so, please notice the behavior and report if you are able to duplicate 
the problem.  My build of NB (Netbeans IDE 5.5 (Build 200610171010).  We only use released builds and we do not have a 
reason to upgrade to 5.5.1, but we can if needed.

Again, genfiles.properties should be kept under version control with the rest of nbproject minus the private subdir.
Currently the IDE provides no special support for resolving CVS merge conflicts in this file. Will need to investigate
effects of such a conflict and various possible resolutions to recommend workaround. Limitations described in issue
#42735 mean that genfiles.properties will be changed rather more often than it really should be when multiple versions
of the IDE are in play; limitations in Ant (in the absence of a scripting language that would make Ant scripts
sufficiently powerful) also cause it to be changed after e.g. additions of subprojects to the classpath.

Are you reviewing this or what?  The priority on this is very high.  When someone turns over a project in which these 
files are added, we are getting loads of conflicts and it is corrupting the project.  We cannot recover from this.  We 
have to manually merge changes and create a new project to resolve this issue.  Even if we manually try to resolve the 
conflict in genfiles.properties file we get the ??? project name when we reopen in NetBeans.

So, after some experimentation, it seems that you can resolve all conflicts, so long as you know what to do: delete
build-impl.xml, merge project.xml and project.properties in a natural way, delete certain entries in
genfiles.properties, reopen project. Scenario:

1. Start 070927 in fresh userdir, JDK 6, Ubuntu.

2. Make new j2seproject (class library) "p1" in some scratch dir.

3. cvs -d repo init

4. Versioning > Import into CVS Repository on p1 into repo, with repo folder "p".

5. Checkout "p" from repo in folder p2.

6. Make two lib projects l1 and l2.

7. In p1, add l1 to CP. Commit.

8. In p2, add l2 to CP. Try to commit; can't, remotely modified.

9. Update p2. Conflicts in build-impl.xml, genfiles.properties, project.properties, project.xml. p2 name displayed as
"???" (due to malformed XML in project.xml).

10. Manually resolve conflicts in project.xml (just remove conflict markers and retain both <reference>s in the
<references> sections). Save. Project name corrected.

11. Manually resolve conflicts in project.properties - keep both project.l?.jar and reference.l?.jar definitions, join
javac.classpath components with ':'. Save. "l1" and "l2" should both appear in Libraries node (might require restart of
IDE; had to redo this step the first time around due to a mistake in project.xml).

12. Delete build-impl.xml.

13. In genfiles.properties, delete conflicted build.xml.data.CRC32 and nbproject/build-impl.xml.data.CRC32;
nbproject/build-impl.xml.script.CRC32 also seems to be conflicted, delete too. Leave build.xml.script.CRC32,
build.xml.stylesheet.CRC32, and nbproject/build-impl.xml.stylesheet.CRC32 alone. Save.

14. Close and reopen project. build-impl.xml is regenerated. Missing properties in genfiles.properties recreated.

15. p2 should now be fixed; commit.

16. Update p1; it should now have both l1 and l2 as deps.

This state of affairs has been constant since the Ant-based project infrastructure was introduced in NB 4.0, so far as I
know; at that time it was decided not to spend effort writing a special VCS merge handler for project metadata. Such a
handler would be a possibility, though not for 6.0 - there is no SPI for adding merge handlers for particular kinds of
files when performing merge operations in a supported VCS (the IDE simply runs the CVS update operation or whatever with
its default merge tool), and this is well past the time for adding significant new interfaces and features.

Downgrading to P3 on the grounds that there is an effective workaround, though it is certainly clumsy.

Behaving as designed for now.

It's not clear from the discussion what happens if genfiles.properties is simply omitted from version control.  In my testing, it appears that the lines that begin "build.xml.*" aren't re-created if the file is removed then regenerated (e.g. upon opening the project), but I don't know what the consequences of that are.  And whatever they are, it seems that if those entries can be created in the first place they ought to be re-creatable later.

Also, I have the most difficulty with this issue not with conflicts between users (especially since there is only one :-), but when upgrading to newer versions of NB.  I've gotten in the habit of simply leaving genfiles.properties editable (I do all checkouts read-only) and not bothering to ever check it in.

(In reply to comment #9)
> I don't know what the consequences of that are

Inability to recreate build-impl.xml after making changes which would require it, typically after adding or removing subprojects. Ideally, build-impl.xml would be nearly static (being at most upgraded with an IDE upgrade that fixes some bugs); but it is not clear that Ant's standard tasks are expressive enough to handle certain kinds of parametric variance, such as in the number of subprojects - without using <script> + Rhino, Ant is just a very poor scripting language. Therefore some aspects of project.xml can change what build-impl.xml looks like. genfiles.properties keeps track of what version of project.xml build-impl.xml was generated from, permitting it to be safely regenerated if and only if the user has not since made manual edits.

> when upgrading to newer versions of NB

These changes should only be in one direction, from older content to newer content, so should not in themselves produce merge conflicts.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss