project, methods, protocol
Matt Jones
jones at nceas.ucsb.edu
Mon Aug 26 10:54:31 PDT 2002
Peter, I'm sorry you're having difficulty working with CVS. It takes a
little bit of persistence because it requires a slightly different way
of working to coordinate with other developers. But the benefit is that
you get pretty much seamless control of files across multiple
developers. And I *never* lose anything that I've done.
When I am working in CVS, I get a conflict about once in 50 or 100
commits, mainly because I haven't communicated with the other developers
well enough to know we're both working on the same part of one file.
Under normal usage (when yours are the only changes to a file), you
shouldn't ever get a conflict. Given that you're having such problems,
here are some possible issues...
First, the conflicts you are seeing could be due to white space. XML Spy
still does some weird stuff each time you edit (changing white space
around). This could be either spaces, tabs, or newlines. So that may
be the source of the problem. But I've edited these files in spy a
bunch of times and never gotten a conflict. Rather, it just changes the
whole file formatting which makes it look like the whoel thing has been
changed. So....I think this is an unlikely source of conflicts, but
possibly a large source of insignificant formatting changes. Running
'cvs diff -bB whatever.xsd' should be much better if this is the case.
If you're using WinCVS, you can launch an external diff program that is
more graphical -- I use WinMerge and it works pretty well.
Second, editing a separate copy of the files is almost always going to
cause problems. CVS is intended to create one (or more) working copies
of the files that you can work on directly. Running a CVS command like
"cvs update" on a working directory with files you have modified should
merge your changes in with the others that have been done by other
developers. Here's the procedure I use pretty much all of the time:
1) Before making changes, 'cvs update -d'. I do this a lot. 100 times
a day or more. Stay in sync and you'll have far fewer problems.
2) Edit files in the working directory. Make discrete changes for one
type of thing only (ie, don't spread changes over the whole file,
because this makes it harder to coordinate with other developers, unless
you know you're the only one working on the file). If you want to
reformat a file (e.g., whitespace), do it in a spearate commit from
content changes. Use software that allows you to know exactly what you
are changing so you'll see problems caused by merging with other developers.
3) When you're ready to commit, first do a 'cvs update -d' to merge with
other developers. If you have made limited changes to only one or two
files, this almost always works without a conflict. If it does have a
conflict (a 'C' status message), you MUST resolve the conflict before
committing (read the CVS docs on conflicts). If it merges changes from
another developer, you'll probably want to make sure there are no
logical inconsistencies in the merge.
4) Do your commit (cvs commit)
Branches are useful when what you are going to do might break the source
for other developers. I use branches on source dirs when I am making
massive changes that will cause it to not compile. In terms of EML,
they would more be used to prevent validation problems or just track a
separate set of changes. When you are done with the branch, you can
merge it to the head pretty automatically (using -kk on ascii files
avoids conflicts), although you may run into some conflicts if others
have also made significant changes to the trunk. In general you could
probably get away without the branch unless you're making radical changes.
Hope these suggestions help. If you continue running into problems,
please give me or Chad a call when you're trying to do it and we'll try
to help.
Matt
Peter McCartney wrote:
> Ok ive done that and of course i now have conflicts between what you
> checked in and what was in my directory. It appears that diff blocked
> out the entire file - how do i tell which segment comes from where? Is
> there no interface like visual sourcesafe that can help one resolve
> these things interactivly? I remember being very frustrated during the
> beta9 process from losing changes and having to keep reading these
> confilicted files. As a result, i typically make a separate copy of the
> cvs directory to to edits in a protected environment. I think im
> beginning to understand how branches are a slightly better way to do
> that, but it still leaves us with the reconiliation process if someone
> continues to edit the same file in the main branch.
>
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental Studies
> Arizona State University
> 480-965-6791
>
> -----Original Message-----
> From: Chad Berkley [mailto:berkley at nceas.ucsb.edu]
> Sent: Monday, August 26, 2002 9:13 AM
> To: Peter McCartney
> Cc: 'Tim Bergsma'; Eml-Dev (E-mail)
> Subject: Re: project, methods, protocol
>
>
> Peter,
>
> I added your changes to CVS under the branch
> EML_PROSPECTIVE_CHANGES_082602. To get this branch, change into your
> eml directory (that you have checked out from cvs) and issue the
> command:
> cvs update -r EML_PROSPECTIVE_CHANGES_082602
> your working directory should now be using the branched files and any
> files you commit will be commited to the branch only. to get your
> working directory back to the root, issue the command:
> cvs update -A
>
> the -r switch updates to a specified revision, in this case the tag.
> once you do this, you should see that the versions of the files now have
> an extra two periods in them. i.e. instead of 1.1, the revision number
> would be 1.1.2.1. The last part of the revision number is the revision
> within the branch. if you changed the file with id 1.1.2.1 and commited
> it, the revision would change to 1.1.2.2. When you move your working
> directory back into the root of the tree (using the -A switch), the
> revision number should go back to 1.1.
>
>
> to create a branch, you issue the following commands after changing into
> the eml directory:
> cvs tag -b SOME_MEANINGFUL_ID
> cvs update -r SOME_MEANINGFUL_ID
>
> the cvs tag command creates the branch. the update command makes your
> working directory work within the branch. You have to do both.
>
> just so you know, you can view all of the branches and other tags by
> doing a cvs log on any file in the directory. at the top of the log, it
> will show the current tags and branches associated with that file.
>
> chad
>
> On Fri, 2002-08-23 at 14:31, Peter McCartney wrote:
> > Tim et. al.
> >
> > I cant figure out how to do the branch thing within cvs so im just doing
> > this through email. If you thinke this is no the right track, then
> ill make
> > a full version that works with all the schemas and get help to figure
> out
> > the branch submission.
> >
> > As a trial balloon for the project/protocol bug, Ive made changes to
> > eml-project and eml-protocol, and ive created a new file called
> eml-method.
> >
> > to summarize
> >
> > eml-project loses sampling, but gains a recursive link to itself.
> >
> > eml-method is a new module that is meant to be imported into dataset,
> > entitybase and attribute. It contains elements for sampling,
> qualityControl
> > (that is actions you took during data collection to control quality),
> and
> > methodsteps. each methodstep contains a description (which may be any
> > combination of a text description, pointer to a citation, or pointer
> to a
> > protocol), instrumentation, source data, software.
> >
> > eml-protocol is simplied to just a text description, with optional
> elements
> > for sofware, instrumentation or qualitycontrol (but not datasets,
> because we
> > cant really say a generic method requires a specific dataset).
> eml-protocol
> > is linked only in eml-method - existing links to
> >
> > Peter McCartney (peter.mccartney at asu.edu)
> > Center for Environmental Studies
> > Arizona State University
> > 480-965-6791
> >
> >
> --
> -----------------------
> Chad Berkley
> National Center for
> Ecological Analysis
> and Synthesis (NCEAS)
> berkley at nceas.ucsb.edu
> -----------------------
>
--
*******************************************************************
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
Interested in ecological informatics? http://www.ecoinformatics.org
*******************************************************************
More information about the Eml-dev
mailing list