You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Noam Tamim <no...@gmail.com> on 2005/11/21 20:57:32 UTC
managing visual studio project files in branches
Hi.
We recently moved from VSS to SVN. The move was great, everybody's happy,
and now we're starting to use the more advanced features - mainly branching
and merging.
Our VS.Net project files (these are extremely verbose XML files, that
contain all configuration and file information of the project) are under
source control (this is how it was with VSS, so we just went on with it). We
have added the needs-lock property to these files - so while everyone works
on the trunk, we're fine.
A problem arises when branching.
1. A user creates a branch of the tree (copies the trunk).
2. That user adds a new VS configuration. VS adds a few XML elements to many
places in the project file. It also changes some other stuff.
3. Someone working on the trunk also adds a configuration.
4. The branch user wants to merge his changes into the trunk. The code
merges fine, but the project files are conflicted: SVN doesn't know how to
deal with the change.
What do other teams do with that? In VSS we didn't have that problem simply
because we never branched.
Thanks in advance,
Noam.
Re: managing visual studio project files in branches
Posted by al...@muly.dk.
Quoting Noam Tamim <no...@gmail.com>:
> Since there's no easy (automatic) way to merge VS project files, let's think
> of them as binary files. What would you do then? Or is it just impossible?
hmm, unless you have a lot of differences in the project files i think
its relativily easy to "hand-merge" with Beyond Compatre for instance.
even if the developer responsible for the correspooding proj files
would lock them he would then have to hand-merge after having recevied
the new updates/changes by the branch developer.
./allan
> On 11/22/05, allan juul <al...@muly.dk> wrote:
>>
>> Noam Tamim wrote:
>>
>> > Hi.
>> >
>> > We recently moved from VSS to SVN. The move was great, everybody's
>> happy,
>> > and now we're starting to use the more advanced features - mainly
>> branching
>> > and merging.
>> >
>> > Our VS.Net project files (these are extremely verbose XML files, that
>> > contain all configuration and file information of the project) are under
>> > source control (this is how it was with VSS, so we just went on with
>> it). We
>> > have added the needs-lock property to these files - so while everyone
>> works
>> > on the trunk, we're fine.
>> >
>> > A problem arises when branching.
>> > 1. A user creates a branch of the tree (copies the trunk).
>> > 2. That user adds a new VS configuration. VS adds a few XML elements
>> to many
>> > places in the project file. It also changes some other stuff.
>> > 3. Someone working on the trunk also adds a configuration.
>> > 4. The branch user wants to merge his changes into the trunk. The code
>> > merges fine, but the project files are conflicted: SVN doesn't know
>> how to
>> > deal with the change.
>> >
>> > What do other teams do with that? In VSS we didn't have that problem
>> simply
>> > because we never branched.
>> >
>> > Thanks in advance,
>> > Noam.
>> >
>>
>>
>> but, is this really a branch or VS proj file problem ? isn't it just
>> because you really have a conflict in a file because svn cannot possibly
>> know how to merge because the actual lines that are edited in the two
>> project files overlap ?
>>
>> i don't know how to deal with this. it would be nice if the studio would
>> leave files intact so different version would better compare. i think VS
>> always "screw" the formatting back to its default look everytime you
>> save a project from within the studio.
>>
>>
>> ./allan
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: managing visual studio project files in branches
Posted by Mark Parker <ma...@msdhub.com>.
Noam Tamim wrote:
> Since there's no easy (automatic) way to merge VS project files, let's
> think of them as binary files. What would you do then? Or is it just
> impossible?
Are you hand-editing the project files?
We merge vs.net project files all the time. Sometimes we get conflicts,
but they're never too hard to straighten out. It's XML, so it's pretty
easy to know if you got something wrong.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: managing visual studio project files in branches
Posted by Noam Tamim <no...@gmail.com>.
Since there's no easy (automatic) way to merge VS project files, let's think
of them as binary files. What would you do then? Or is it just impossible?
On 11/22/05, allan juul <al...@muly.dk> wrote:
>
> Noam Tamim wrote:
>
> > Hi.
> >
> > We recently moved from VSS to SVN. The move was great, everybody's
> happy,
> > and now we're starting to use the more advanced features - mainly
> branching
> > and merging.
> >
> > Our VS.Net project files (these are extremely verbose XML files, that
> > contain all configuration and file information of the project) are under
> > source control (this is how it was with VSS, so we just went on with
> it). We
> > have added the needs-lock property to these files - so while everyone
> works
> > on the trunk, we're fine.
> >
> > A problem arises when branching.
> > 1. A user creates a branch of the tree (copies the trunk).
> > 2. That user adds a new VS configuration. VS adds a few XML elements
> to many
> > places in the project file. It also changes some other stuff.
> > 3. Someone working on the trunk also adds a configuration.
> > 4. The branch user wants to merge his changes into the trunk. The code
> > merges fine, but the project files are conflicted: SVN doesn't know
> how to
> > deal with the change.
> >
> > What do other teams do with that? In VSS we didn't have that problem
> simply
> > because we never branched.
> >
> > Thanks in advance,
> > Noam.
> >
>
>
> but, is this really a branch or VS proj file problem ? isn't it just
> because you really have a conflict in a file because svn cannot possibly
> know how to merge because the actual lines that are edited in the two
> project files overlap ?
>
> i don't know how to deal with this. it would be nice if the studio would
> leave files intact so different version would better compare. i think VS
> always "screw" the formatting back to its default look everytime you
> save a project from within the studio.
>
>
> ./allan
>
Re: managing visual studio project files in branches
Posted by allan juul <al...@muly.dk>.
Noam Tamim wrote:
> Hi.
>
> We recently moved from VSS to SVN. The move was great, everybody's happy,
> and now we're starting to use the more advanced features - mainly
branching
> and merging.
>
> Our VS.Net project files (these are extremely verbose XML files, that
> contain all configuration and file information of the project) are under
> source control (this is how it was with VSS, so we just went on with
it). We
> have added the needs-lock property to these files - so while everyone
works
> on the trunk, we're fine.
>
> A problem arises when branching.
> 1. A user creates a branch of the tree (copies the trunk).
> 2. That user adds a new VS configuration. VS adds a few XML elements
to many
> places in the project file. It also changes some other stuff.
> 3. Someone working on the trunk also adds a configuration.
> 4. The branch user wants to merge his changes into the trunk. The code
> merges fine, but the project files are conflicted: SVN doesn't know
how to
> deal with the change.
>
> What do other teams do with that? In VSS we didn't have that problem
simply
> because we never branched.
>
> Thanks in advance,
> Noam.
>
but, is this really a branch or VS proj file problem ? isn't it just
because you really have a conflict in a file because svn cannot possibly
know how to merge because the actual lines that are edited in the two
project files overlap ?
i don't know how to deal with this. it would be nice if the studio would
leave files intact so different version would better compare. i think VS
always "screw" the formatting back to its default look everytime you
save a project from within the studio.
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org