[jitsi-dev] project files


#1

Hey all,

I am regularly having conflicts on project files such as .classpath jitsi.ipr, jitsi.iml and others. As a result, sharing those files is primarily a source of problems for me and causes me to waste more time than the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those files back into IDE specific directories is the first thing that came to my mind.

Other suggestions?

Emil

···

--
https://jitsi.org


#2

.git/config/exclude -> make an entry there so that they are ignored for you.

AFAIK another reliable solution that is widely used, is to remove these files from source control and let them be generated by Maven or Ivy.
Benefit of this would be to have source attachments for all the libs (provided we use maven central or a properly set up repo of our own).
IntelliJ for example even supports to open a pom.xml directly - try it with dnssecjava...

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 17.01.2014 à 09:01, "Emil Ivov" <emcho@jitsi.org> a écrit :

Hey all,

I am regularly having conflicts on project files such as .classpath jitsi.ipr, jitsi.iml and others. As a result, sharing those files is primarily a source of problems for me and causes me to waste more time than the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those files back into IDE specific directories is the first thing that came to my mind.

Other suggestions?

Emil

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hi Emil,

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those files
back into IDE specific directories is the first thing that came to my mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Regards,
Pawel

···

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:


#4

.git/config/exclude -> make an entry there so that they are ignored for you.

That's the first thing I tried and it didn't do the trick I was still having problems (although maybe it was different problems).

AFAIK another reliable solution that is widely used, is to remove these files from source control and let them be generated by Maven or Ivy.
Benefit of this would be to have source attachments for all the libs (provided we use maven central or a properly set up repo of our own).
IntelliJ for example even supports to open a pom.xml directly - try it with dnssecjava...

That is quite interesting. Especially given that we could use a repo of our own (I am horrified by the option of relying on a third party repo for our dependencies).

I am not a fan of maven and how it creates a complicated infratructure, automake style, but ivy seemed fairly non-intrusive. We should definitely look into this.

Emil

···

On 17.01.14, 09:33, Ingo Bauersachs wrote:

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

Le 17.01.2014 à 09:01, "Emil Ivov" <emcho@jitsi.org> a écrit :

Hey all,

I am regularly having conflicts on project files such as .classpath jitsi.ipr, jitsi.iml and others. As a result, sharing those files is primarily a source of problems for me and causes me to waste more time than the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those files back into IDE specific directories is the first thing that came to my mind.

Other suggestions?

Emil

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#5

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am not being helpful by saying what they were. I just don't remember. I'll try this again soon and let you know.

Emil

···

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those files
back into IDE specific directories is the first thing that came to my mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

--
https://jitsi.org


#6

Hello sir its leo here,i hope you all are doing well.I have a query
actually when i get myself registered on my xmpp server,i get registered
successfully no issue but after registering when i call a contact,the call
window is showing "/jitsi" at end.Iam attaching a picture of it.Please tell
me how to remove this "/jitsi" from source code.It would be a great help.

···

On Fri, Jan 17, 2014 at 8:59 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:33, Ingo Bauersachs wrote:

.git/config/exclude -> make an entry there so that they are ignored for
you.

That's the first thing I tried and it didn't do the trick I was still
having problems (although maybe it was different problems).

AFAIK another reliable solution that is widely used, is to remove these

files from source control and let them be generated by Maven or Ivy.
Benefit of this would be to have source attachments for all the libs
(provided we use maven central or a properly set up repo of our own).
IntelliJ for example even supports to open a pom.xml directly - try it
with dnssecjava...

That is quite interesting. Especially given that we could use a repo of
our own (I am horrified by the option of relying on a third party repo for
our dependencies).

I am not a fan of maven and how it creates a complicated infratructure,
automake style, but ivy seemed fairly non-intrusive. We should definitely
look into this.

Emil

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

Le 17.01.2014 à 09:01, "Emil Ivov" <emcho@jitsi.org> a écrit :

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
    jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

···

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org


#8

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

···

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:

So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
    jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org

--
https://jitsi.org


#9

- I revert changes to source attaches as soon as I'm done and only use them when absolutely necessary (changes to .classpath causes a complete, slow recompile in Eclipse)
- Commit new libs as soon as possible, or commit them in a branch and deal with the merge

But: EVERY time theres no source attached, I swear around that I have to deal with that shit. I rather want that to delegate this job to a proper dependency management system (which not only deals with source attachments, but also avoids having binaries in the tree and attaches the Javadocs as well). Now I long wanted to start working in this, but I never did because:
- It's a lot of work
- I'd prefer to use Maven than hacking Ivy into the existing build, but
-- it would cause even more work
-- I'm not a Maven expert
-- Emil considers it Voodoo
- I fear to make this work (be it Ivy or Maven) for nothing as it wouldn't fit someones current preferences or workflow

And on the last point: now would be time for everyone on the team to speak up and state preferences and opinions.

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

···

On 23.02.2014, at 16:00, "Emil Ivov" <emcho@jitsi.org> wrote:

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:
So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
   jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Hi Emil,

I don't quite see your problem. My workflow is typically the following:

Initial set-up:
1. clone git repo (using commandline git client)
2. (in my case) import project into Eclipse. Just leave the project
files on the location they are now.
3. Set up run configuration with environment variables.

Then when I need to switch branches:
1. git checkout <branch/hash>
Result: code modified in place, Eclipse (with Git plugin) will adjust
accordingly.

or in case of getting new commits
1. git fetch
2. git rebase origin/master
Result: my current branch rebases to tip of Jitsi-branch

In the case where I do have changed files, I typically stash them
temporarily, switch branches and unstash them. Also, I gnerally forget
that 'add'-ed files still get stashed if you do not use the
'--keep-index' argument. Other than this, it is mostly effortless.

I occasionally see a new jar library being added, but that does not
often collide. In the beginning I did do some additional configuration
in the Eclipse classpath file, but since that is XML it is easy to merge
by hand. Eclipse does not change the project file unless the project
configuration is actually changed, so this makes it easier.

Up to now a fairly pleasant experience.

Danny

···

On 02/23/2014 03:58 PM, Emil Ivov wrote:

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:

So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
    jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org


#11

- I revert changes to source attaches as soon as I'm done

OK, so it's basically unusable.

and only use them when absolutely necessary (changes to .classpath causes a complete, slow recompile in Eclipse)
- Commit new libs as soon as possible, or commit them in a branch and deal with the merge

But: EVERY time theres no source attached, I swear around that I have to deal with that shit. I rather want that to delegate this job to a proper dependency management system (which not only deals with source attachments, but also avoids having binaries in the tree and attaches the Javadocs as well). Now I long wanted to start working in this, but I never did because:
- It's a lot of work
- I'd prefer to use Maven than hacking Ivy into the existing build, but
-- it would cause even more work
-- I'm not a Maven expert
-- Emil considers it Voodoo

Well ... first this is not accurate and second I'd rather do my own tech statements.

- I fear to make this work (be it Ivy or Maven) for nothing as it wouldn't fit someones current preferences or workflow

Indeed and that's why I expressed a preference for Ivy: it simply seems far less disruptive to the current workflow. The whole thing is really not that urgent though: its plumbery and there's always more dev work on the list so ....

Emil

···

On 24.02.2014, at 00:09, Ingo Bauersachs <ingo@jitsi.org> wrote:

And on the last point: now would be time for everyone on the team to speak up and state preferences and opinions.

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

On 23.02.2014, at 16:00, "Emil Ivov" <emcho@jitsi.org> wrote:

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:
So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
  jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#12

Hi Emil,

I don't quite see your problem.

Yeah ... I was mostly expressing frustration. I am a well known git fan.

My workflow is typically the following:

Initial set-up:
1. clone git repo (using commandline git client)
2. (in my case) import project into Eclipse. Just leave the project
files on the location they are now.
3. Set up run configuration with environment variables.

I am not using Eclipse and with IntelliJ I need to make changes to the environment in order for it to behave the way I need it to.

Then when I need to switch branches:
1. git checkout <branch/hash>
Result: code modified in place, Eclipse (with Git plugin) will adjust
accordingly.

Oh wow! I've never seen this actually happen :). I would *always* get conflicts on project files. Trying to make git ignore them has been a remarkable waste of time and at some point it always ends up attempting to merge them.

The same issues apply when moving through branches.

or in case of getting new commits
1. git fetch
2. git rebase origin/master
Result: my current branch rebases to tip of Jitsi-branch

Same as above. Things never work out for me that way.

In the case where I do have changed files, I typically stash them
temporarily, switch branches and unstash them.

Except that I also get conflicts when unstashing .... :slight_smile:

Also, I gnerally forget
that 'add'-ed files still get stashed if you do not use the
'--keep-index' argument. Other than this, it is mostly effortless.

I occasionally see a new jar library being added, but that does not
often collide.

That's one of my main grievanes. Working on ice4j for example, irrevocably causes conflicts on ice4j.jar as soon as someone touches it in the repo.

In the beginning I did do some additional configuration
in the Eclipse classpath file, but since that is XML it is easy to merge
by hand. Eclipse does not change the project file unless the project
configuration is actually changed, so this makes it easier.

Up to now a fairly pleasant experience.

I really and sincerely envy you!

Emil

···

On 24.02.2014, at 00:20, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Danny

On 02/23/2014 03:58 PM, Emil Ivov wrote:

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:

So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
   jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#13

- I revert changes to source attaches as soon as I'm done

OK, so it's basically unusable.

Yes.

and only use them when absolutely necessary (changes to .classpath causes a complete, slow recompile in Eclipse)
- Commit new libs as soon as possible, or commit them in a branch and deal with the merge

But: EVERY time theres no source attached, I swear around that I have to deal with that shit. I rather want that to delegate this job to a proper dependency management system (which not only deals with source attachments, but also avoids having binaries in the tree and attaches the Javadocs as well). Now I long wanted to start working in this, but I never did because:
- It's a lot of work
- I'd prefer to use Maven than hacking Ivy into the existing build, but
-- it would cause even more work
-- I'm not a Maven expert
-- Emil considers it Voodoo

Well ... first this is not accurate and second I'd rather do my own tech statements.

Well, sorry. That was my apparently wrong memory from Fosdem. The point though was that at least someone would be uncomfortable with it.

- I fear to make this work (be it Ivy or Maven) for nothing as it wouldn't fit someones current preferences or workflow

Indeed and that's why I expressed a preference for Ivy: it simply seems far less disruptive to the current workflow.

True. The point of not using Ivy but some more automated build system would only be beneficial in the long term, if at all.

The whole thing is really not that urgent though: its plumbery and there's always more dev work on the list so ....

Also true, but it would probably accelerate that other dev work when we wouldn't have to deal with searching for sources...

Well, as long as nobody else is even the slightest bit interested in it, I surely won't devote any time to it.

Ingo

···

Le 24.02.2014 à 16:59, "Emil Ivov" <emcho@jitsi.org> a écrit :

On 24.02.2014, at 00:09, Ingo Bauersachs <ingo@jitsi.org> wrote:

Emil

And on the last point: now would be time for everyone on the team to speak up and state preferences and opinions.

Freundliche Grüsse,
Ingo Bauersachs

-- Sent from my tablet

On 23.02.2014, at 16:00, "Emil Ivov" <emcho@jitsi.org> wrote:

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:
So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

Hmm... if that is the case, I feel like I am staring "into my own
future", reading up on the horrors that may await me ...

I assume you know about all the usual tricks of ignoring particular
files that are user-specific, such as workspace profile configurations,
in either Eclipse or IntelliJ. Those are also fairly easy to find on the
internet. (For example:
https://intellij-support.jetbrains.com/entries/23393067-How-to-manage-projects-under-Version-Control-Systems)

When I was doing a quick search I did notice some alternative project
configuration that is stored in the '.idea' directory which contains
multiple (smaller, simpler?) files. It might be worthwhile to try out
this new project configuration structure? May be it is easier to merge?

Hi Emil,

I don't quite see your problem.

Yeah ... I was mostly expressing frustration. I am a well known git fan.

My workflow is typically the following:

Initial set-up:
1. clone git repo (using commandline git client)
2. (in my case) import project into Eclipse. Just leave the project
files on the location they are now.
3. Set up run configuration with environment variables.

I am not using Eclipse and with IntelliJ I need to make changes to the environment in order for it to behave the way I need it to.

Then when I need to switch branches:
1. git checkout <branch/hash>
Result: code modified in place, Eclipse (with Git plugin) will adjust
accordingly.

Oh wow! I've never seen this actually happen :). I would *always* get conflicts on project files. Trying to make git ignore them has been a remarkable waste of time and at some point it always ends up attempting to merge them.

The same issues apply when moving through branches.

For completeness I have to say that I do a refresh in Eclipse. But of
course that only works if the checkout was successful.
The classpath file, a simple xml file, would often just merge changes.
And even if a conflict arises, it's typically just a manner of inserting
both or such.

or in case of getting new commits
1. git fetch
2. git rebase origin/master
Result: my current branch rebases to tip of Jitsi-branch

Same as above. Things never work out for me that way.

In the case where I do have changed files, I typically stash them
temporarily, switch branches and unstash them.

Except that I also get conflicts when unstashing .... :slight_smile:

Also, I gnerally forget
that 'add'-ed files still get stashed if you do not use the
'--keep-index' argument. Other than this, it is mostly effortless.

I occasionally see a new jar library being added, but that does not
often collide.

That's one of my main grievanes. Working on ice4j for example, irrevocably causes conflicts on ice4j.jar as soon as someone touches it in the repo.

The only way I can think of is creating a separate branch for this work,
and not updating that as often as you would a normal branch while you
are still working on a "big change".
When checking out another branch in git, you should not get conflicts,
since you are not combining different commits. Instead you're just
getting a different version of the project.

In the beginning I did do some additional configuration
in the Eclipse classpath file, but since that is XML it is easy to merge
by hand. Eclipse does not change the project file unless the project
configuration is actually changed, so this makes it easier.

Up to now a fairly pleasant experience.

I really and sincerely envy you!

It could just be that mine is a very short experience blessed with
ignorance. We'll just have to see :wink:

Danny

···

On 02/24/2014 05:17 PM, Emil Ivov wrote:

On 24.02.2014, at 00:20, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Emil

Danny

On 02/23/2014 03:58 PM, Emil Ivov wrote:

Another more important question actually:

Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?

Emil

On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <emcho@jitsi.org> wrote:

So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:

First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
by checkout:
   jitsi.ipr
Please, commit your changes or stash them before you can switch branches.
Aborting

Any ideas?

Emil

On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 09:44, Paweł Domas wrote:

Hi Emil,

On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
than
the occasional update of .classpath with new jars.

I haven't found reliable ways of making git ignore these files.

I am wondering what the best way to solve this would be. Kicking those
files
back into IDE specific directories is the first thing that came to my
mind.

Other suggestions?

Emil

https://help.github.com/articles/ignoring-files

There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.

Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt

Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt

Thanks Pawel,

I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.

Emil

--
https://jitsi.org

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

I assume you know about all the usual tricks of ignoring particular
files

I think I've tried most of them. The issue is that project files (as such) are not user-specific and I've found no way to locally modify a file that's already in version control and then prevent git from trying to update it when it changes on github.

The only way I can think of is creating a separate branch for this work,
and not updating that as often as you would a normal branch while you
are still working on a "big change".
When checking out another branch in git, you should not get conflicts,
since you are not combining different commits. Instead you're just
getting a different version of the project.

That's the point of it all. You end up accommodating to a very git-specific workflow where you pretty much have to wear the right pair of socks for things to work.

My main complaint is that I didn't want to learn the quirks of git. I no longer have that much time for development and what little I have I'd rather spend ong ice4sip or bundle or rtcp-mux or a server-side focus for jitmeet. NOT on git :).

I am quite convinced now that this is not an option and until layers emerge that either hide gits specifics or do versioning differently, git will be a child that simply demands attention.

Sigh. This is our third VCS so I am just hoping the fourth allows for a smoother migration :slight_smile:

Emil

···

On 24.02.2014, at 21:18, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

--
https://jitsi.org